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Abstract 

The  undisciplined  use  of  shared  mutable  state  can  be  a  source  of  program  errors  when  aliases 
unsafely  interfere  with  each  other.  While  protocol-based  techniques  to  reason  about  interference 
abound,  they  do  not  address  two  practical  concerns:  the  decidability  of  protocol  composition  and 
its  integration  with  protocol  abstraction.  We  show  that  our  composition  procedure  is  decidable  and 
that  it  ensures  safe  interference  even  when  composing  abstract  protocols.  To  evaluate  the  expres¬ 
siveness  of  our  protocol  framework  for  ensuring  safe  shared  memory  interference,  we  show  how 
this  same  protocol  framework  can  be  used  to  model  safe,  typeful  message-passing  concurrency 
idioms. 
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1  Introduction 


The  interactions  that  can  occur  via  shared  mutable  state  can  be  a  source  of  program  errors.  When 
different  clients  access  the  same  mutable  state,  their  actions  can  potentially  interfere.  For  instance, 
the  programmer  may  wrongly  assume  that  a  cell  holds  a  particular  type,  when  another  part  of  the 
program  has  changed  that  cell  to  hold  a  different  type.  When  this  happens,  the  program  may  fault 
due  to  unsafe  interference  caused  by  unexpected  actions  through  other  aliases  to  that  shared  state. 
Thus,  to  reason  about  interference  we  must  reason  about  how  state  is  aliased  and  how  the  different 
aliases  use  the  shared  state. 

Our  technique  builds  on  the  use  of  linear  capabilities  [1]  to  track  type-changing  resource  mu¬ 
tation  within  the  framework  of  a  linear  type  system.  However,  relying  solely  on  linearity  is  often 
too  restrictive.  For  instance,  linearity  enforces  exclusive  ownership  of  mutable  state,  which  is  in¬ 
compatible  with  multithreading — i.e.  linearity  forbids  sharing.  To  allow  sharing,  we  extend  the 
concept  of  rely -guarantee  protocols  [21].  By  sequencing  steps  of  “rely=»guarantee”  actions,  each 
protocol  characterizes  an  alias’s  local,  isolated  perspective  on  interactions  with  a  piece  of  shared 
state: 


“what  I  assume  about  the  state”  =>  “what  I  guarantee  about  the  state”  ;  next  step 

current  step 

Since  the  interactions  performed  by  an  alias  may  change  over  time,  a  rely-guarantee  protocol  is 
formed  by  a  sequence  of  steps  that  specify  each  interfering  action.  Each  step  relies  on  the  shared 
state  having  some  type  and  then,  after  some  private  actions,  guarantees  that  the  shared  state  will 
now  have  some  other  type,  which  becomes  visible  to  other  aliases.  By  constraining  the  actions 
of  each  alias,  we  can  make  strong  assumptions  about  the  kind  of  interference  that  an  alias  may 
produce,  in  the  spirit  of  rely-guarantee  reasoning  [16].  Naturally,  not  all  protocols  compose  safely. 
While  a  protocol  describes  its  own  actions  on  a  piece  of  shared  state,  protocol  composition  will 
ensure  that  those  actions  are  safe  w.r.t.  the  actions  that  can  be  done  via  other  existing  (and  even 
future)  protocols  over  that  state.  Composition  is  safe  only  if  the  set  of  protocols  accounts  for  all 
possible  run-time  action  interleavings. 

Our  main  contribution  is  a  decidable  protocol  composition  procedure  that  also  allows  abstract 
protocols  to  be  composed.  We  break  down  our  contributions  as  follows: 

•  We  adapt  the  existing  constructs  of  rely-guarantee  protocols  [21]  to  work  in  a  system  with 
concurrent  runtime  semantics,  and  show  that  rely-guarantee  protocols  are  useful  to  reason 
about  safe  interference  in  the  concurrent  setting. 

•  We  give  an  axiomatic  definition  of  protocol  composition.  We  show  that  this  procedure  can  be 
implemented  in  a  sound  and  complete  (w.r.t.  the  formal  definition)  algorithm  that  terminates 
on  all  legal  inputs.1  The  protocol  composition  algorithm  is  implemented  in  a  prototype.2 

'Note  that  we  have  not  proven  the  decidability  of  the  entire  type  system,  but  only  of  the  protocol  composition 
algorithm  which  is  at  its  core.  The  remainder  of  the  type  system  is  more  conventional  and  we  did  not  encounter 
difficulties  with  decidability  when  implementing  similar  rules  in  our  prior  work  [21], 

2See:  http://www.es . cmu.edu/~foliveir/protocol-coraposition.html 
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x  6  Variables  t  6  Tags  f  6  Fields  p  e  Location  Constants 


e  ::=  v 

(value) 

|  lock  v 

(lock  locations) 

1  v.f 

(field  selection) 

|  unlock  v 

(unlock  locations) 

|  V  V 

(application) 

|  fork  e 

(spawn  thread) 

|  let  a  =  e  in  e  end 

(let) 

|  new  v 

(cell  creation) 

v  ::=  p 

(address) 

|  delete  v 

(cell  deletion) 

1  * 

(variable) 

1  !v 

(dereference) 

|  Ax.e 

(function) 

|  v  :=  v 

(assign) 

1  {f  =  v} 

(record) 

|  case  v  of  t#x  ->  e  end 

(case) 

|  t#v 

(tagged  value) 

Notes:  Z  is  a  potentially  empty  sequence  of  Z  elements. 

p  is  not  source-level. 

Figure  1:  Values  (v)  and  expressions  ( e ). 


•  We  show  that  our  use  of  type  abstraction  and  bounded  quantification  at  the  protocol  level 
enables  us  to  model  new,  and  more  general,  polymorphic  forms  of  safe  modular  shared  state 
interactions. 

•  We  prove  our  system  sound  through  progress  and  preservation  theorems  that  show  the  ab¬ 
sence  of  unsafe  interference  in  correctly  typed  programs.  Our  design  ensures  memory  safety 
and  data-race  freedom,  where  linear  resources  are  shared  via  protocol  composition  (a  partial 
commutative  monoid  [19,  8]). 

•  We  evaluate  the  expressiveness  of  our  system  by  discussing  how  our  core  shared  memory 
protocol  framework  is  capable  of  expressing  safe,  typeful  message -passing  idioms. 

Next,  we  briefly  introduce  the  language  that  “hosts”  our  protocols,  with  the  remaining  text  fo¬ 
cused  on  discussing  new  protocol-level  features.  Sections  2  and  3  introduce  our  novel  definition  of 
protocol  composition  and  its  extensions  to  support  abstract  protocols.  Section  4  discusses  technical 
results.  The  paper  ends  with  discussions  of  expressiveness,  related  work,  and  conclusions. 

1.1  Preliminaries:  Language  Overview 

Our  language  supports  fork/join  concurrency  combined  with  lock-based  mutual  exclusion,  where 
all  threads  share  a  common  heap.  We  use  the  variant  of  the  polymorphic  /1-calculus  shown  in  Fig. 
1.  For  convenience,  the  grammar  is  let-expanded  [31]  so  that  all  constructs,  except  let,  are  defined 
over  values.  The  language  includes  first-class  functions  (T),  records  ({f  =  v})  that  label  a  value 
as  f,  and  tagged  values  (t#v)  to  mark  a  value  with  a  tag.  Standard  constructs  are  used  for  field 
selection,  application,  let  blocks,  memory  allocation,  deletion,  assignment,  dereference,  and  case 
analysis,  “lock  v”  atomically  locks  a  non-empty  set  of  locations  (ensuring  both  mutual  exclusion 
and  forbidding  re-entrant  uses)  and  analogously  with  “unlock  v”.  “fork  e"  executes  the  expression 
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//  assume  ‘y’  in  scope 
y  :=  "ok!"; 


y  :  !ref  1,  rw  1  int 
y  :  !ref  1,  rw  1  string 
x  :  !ref  1,  y  :  !ref  1,  rw  1  string 
x  :  !ref  1,  y  :  !ref  1,  rw  1  boolean 
x  :  !ref  1,  y  :  !ref  1 


let  x  =  y  in 
x  :=  false; 
delete  x; 

!y  //Type  Error:  missing  capability  to  location  T. 


Figure  2:  Tracking  linear  capabilities. 


in  a  new  thread  while  sharing  access  to  the  common  global  heap.  The  operational  semantics  are 
standard  and,  as  such,  are  only  shown  in  the  appendix.  They  produce  the  standard  evaluation  of 
the  language’s  constructs  such  as  creating  or  deleting  memory,  spawning  new  threads,  etc. 

Mutable  References  We  type  mutable  references  by  following  the  design  proposed  in  L3  [1]. 
Therefore,  a  mutable  cell  is  decomposed  into  two  components:  a  pure  reference ,  which  can  be 
freely  copied;  and  a  linear  [13]  capability ,  a  resource  that  is  used  to  track  the  contents  of  that  cell. 
To  link  a  reference  to  its  respective  capability,  we  use  location-dependent  types.  For  instance,  a 
new  cell  has  type  31. (  (!ref  /)  ::  (rw  /  A)  ).  This  type  abstracts  the  fresh  location,  /,  that  was 
created  by  the  memory  allocation.  Furthermore,  we  are  given  a  reference  of  type  “!ref  /”  to  mean 
a  pure/duplicable  (!)  reference  to  a  location  /,  where  the  information  about  the  contents  of  that 
location  is  stored  in  the  linear  capability  for  /.  The  permission  to  access  (e.g.  dereference)  the 
contents  of  a  cell  requires  both  the  reference  and  the  capability  to  be  available. 

Our  capabilities  follow  the  format  “rw  l  A”,  meaning  a  read-write  capability  to  a  location 
/  that  currently  has  contents  of  type  A  (the  type  of  the  value,  given  in  “new  v”,  that  initializes 
the  new  cell).  We  depart  from  [1]  by  making  capabilities  typing  artifacts  that  only  exist  at  the 
level  of  typing.  Consequently,  capabilities  are  managed  implicitly  by  the  type  system  rather  than 
manually  manipulated  by  the  programmer  via  language  constructs.  However,  we  may  still  need 
to  associate  a  capability  with  another  type.  For  this  reason,  we  use  the  notion  of  stacking  [22]. 
In  31. (  (!ref  /)  ::  (rw  /  A)  )  we  see  that  the  capability  to  /  is  stacked  on  top  of  “!ref  /”  since  the 
capability  is  to  the  right  of  the  This  allows  the  capability  to  be  bundled  together  with  the  ref 
type,  but  no  action  is  required  to  unbundle  them  if  they  are  needed  separately.  We  refer  to  prior 
work  [19,  22,  21,  1]  for  more  details  on  the  use  of  capabilities,  locations,  and  stacking,  as  well  as 
convenient  abbreviations.  Here,  it  suffices  to  assume  that  they  are  handled  automatically  by  the 
type  system,  as  our  focus  here  is  on  safely  sharing  the  linear  resources. 

In  the  scheme  above,  all  the  variables  that  reference  the  same  location  also  share  a  single  linear 
(i.e.  “exclusively  owned”  or  “unique”)  capability  that  tracks  the  changes  to  that  location’s  contents 
(as  shown  in  Fig.  2).  However,  this  tracking  relies  on  a  compile-time  approximation  of  how  vari¬ 
ables  alias,  which  constrains  how  state  can  be  used.  Since  the  linear  capability  must  be  (linearly) 
threaded  through  the  program,  this  scheme  forbids  aliasing  idioms  that  require  “simultaneous”  ac¬ 
cess  to  aliased  state,  such  as  when  multiple  threads  share  access  to  a  cell.  To  enable  this  form  of 
sharing,  we  split  a  linear  resource  into  multiple  protocols.  Each  protocol  controls  how  an  alias 
interacts  with  the  shared  state,  without  depending  on  precise  knowledge  of  which  variables  alias 
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x  6  Variables  X  e  Type  Variables  p  e  Location  Constants 
t  6  Tags  f  6  Fields  p  ::=  p\l  u  ::=  l\X 


l  6  Location  Variables 
U  ::=  p\A 


!A 

(pure/persistent) 

A  -o  A 

(linear  function) 

[f  :  A] 

(record) 

Z,  t,-#A; 

(tagged  sum) 

V/.A 

(universal  location) 

31.  A 

(existential  location) 

VX<:A.A 

(bounded  universal  type) 

3X<:A.A 

(bounded  existential  type) 

ref  p 

(reference  type) 

X[U] 

(type  variable) 

(rec  X(u).A)[U] 
A  ©A 
A  &  A 
rw  p  A 

none 

top 

A  ::  A 
A  *  A 
A  =>  A 
A;  A 


(recursive  type) 
(alternative) 

(intersection) 

(read-write  capability  to  p) 
(empty  resource) 

(top) 

(stacking) 

(separation) 

(rely) 

(guarantee) 


Notes:  we  simplify  X\ ]  to  X:  ©,  &,  *,  +  are  commutative  and  associative. 


Figure  3:  Types  (A). 


each  other.  We  will  continue  with  a  brief  presentation  of  the  base  language,  before  diving  into  the 
details  of  our  sharing  mechanism  in  Section  2. 

Types  (Note  that  rely  and  guarantee  types  will  only  be  discussed  in  the  next  section,  when  we 
present  sharing).  Our  types  (Fig.  3)  follow  the  connectives  of  linear  logic  [13].  For  this  reason 
a  function  type  uses  -°  (instead  of  — »)  to  denote  a  linear  function.  The  linear  restriction  can  be 
lifted  when  the  type  is  preceded  by  a  “bang”,  such  as  in  !A,  which  denotes  a  pure/duplicable 
type.  Records  are  typed  as  [f  :  A]  where  each  field  f  types  the  value  of  the  record  with  some  type 
A.  Y,i  t i#Aj  denotes  a  single  tagged  type  or  a  sequence  of  tagged  types  separated  by  +  (such  as 
“a#A  +  b #B  +  c#C”).  We  have  separate  existential  and  universal  quantification  over  locations  and 
types,  since  locations  and  types  are  of  different  kinds.  Note  that  we  leave  V/3  as  typing  artifacts 
and  as  such  they  do  not  have  corresponding  constructs  in  the  language.  Quantification  over  types 
can  provide  a  type  bound  (on  the  right  of  <:)  and  where  top  is  assumed  by  default  when  the  bound 
is  omitted. 

Our  recursive  types  (assumed  to  be  non-bottom  types)  are  equi-recursive,  interpreted  co-inductively, 
and  satisfy  the  usual  folding/unfolding  principle: 

(rec  X(u)A)[U]  =  A{(rec  X(u)A)/X}{U/u}  (eq:Rec) 

Recursive  types  may  include  a  list  of  type/location  parameters  (u)  that  are  substituted  by  some 
type/location  (U)  on  unfold,  besides  unfolding  the  recursive  type  variable  (V). 

We  use  ©  to  denote  a  union  of  alternative  types,  and  &  to  denote  a  linear  choice  of  different 
types,  none  is  the  empty  resource.  Finally  we  have  “A0  ::  Ai”  for  stacking  resource  A\  on  top  of 
A0.  Stacking  is  not  commutative,  so  that  it  is  not  guaranteed  that  “A0  ::  A\  ::  A2”  can  be  used  in 
place  of  “A0  ::  A2  ::  A”.  To  enable  resource  commutation,  we  use  *  such  that  “A0  ::  (Ai  *  A2)” 
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r  |  A0  h  e  :  A  H  A] 


Typing  rules,  (t:*) 


(t:Pure) 

T  |  •  h  v  :  A  H  • 

r  |  •  h  v:\A-i- 
(t:Function) 

T  |  A,x  :  A0  h  <?  :  Ai  H 


(t:Pure-Elim) 

r,x  :  A0  |  A0  h  e  :  Ai  h  Aj 
T  |  A0,  x  ’  !A0  h  c  ’  Aj  H  Aj 
(t:  Application) 
r  |  A0  h  Vo  :  Ao 


(t:  Frame) 

F  |  A0  v  e  \  A  -\  Aj 
r  |  A0,  A2  l-  e  :  A  H  A],  Ai 

Ai  H  Ai  T  |  Ai  h  vi  :  Aq  h  A2 


r  |  A  h  Ax. 6  \  A()  — O  A[  H  • 
(t:New) 

T  |  A0  h  v  :  A  H  Ai 


r  |  A0  h  v0  vi  :  Ai  H  A2 
(t:  Delete) 

r  |  A0  h  v  :  3/.((!ref  /)  ::  (rw  /  A))  H  A! 


T  |  A0  h  new  v  :  3/.((!ref  /)  ::  (rw  /  A))  H  A] 
(t:Assign) 

r  |  Ao  h  vi  :  Ao  H  Ai 
T  |  Ai  h  v0  :  ref  p  H  A2,  rw  /?  Ai 

r  |  A0  f  v0  :=  vi  :  Ai  H  A2,  rw  p  A0 
(t:  Dereference-Linear) 
r  |  Aq  h  v  :  ref  pH  Ai,rwpA 

r  |  A0  f-  !v  :  A  H  Ai,rw  p  ![] 

(t:  Sub  sumption) 

r  h  Ao  Aj  r|  Ai  h  e  :  Ao  H  A2 


T  |  A0  h  delete  v  :  3/.A  h  Aj 
(t:Let) 

r  |  Ao  F  e0  ■  Ao  H  Ai 
r|  Aj,x  :  A0  h  ei  :  A i  H  A2 

r  |  A0  f  let  a;  =  e0  in  ex  end  :  A{  h  A2 
(t:  LocOpenB  ind) 

T,  / :  loc  |  A0,  x  :  Ai  h  e  :  A2  H  Ai 
r  |  Ao,  jc  :  3/.Ai  l-  ^  i  A2  h  A] 

r  h  Aq  A  i  r  h  A2  ■<!  A3 


r  I  Ao  h  e  :  Ai  h  A3 

Notes:  bounded  variables  of  a  construct  and  type/location  variables  of  quantifiers  must  be  fresh  in  the  rule’s  conclusion. 

Figure  4:  Typing  rules  (selected). 


and  “A0  ::  (A2  *  A 1 )”  are  interchangeable  via  subtyping.  For  clarity,  we  will  review  these  type 
annotations  as  we  present  examples  further  below.  Note  that  we  do  not  syntactically  distinguish 
resources  (such  as  capabilities  or  protocols)  from  value-inhabited  types.  However,  the  type  system 
ensures  that  types  such  as  none  can  never  be  used  to  type  a  value.  Indeed,  even  though  “wrong” 
types  can  be  assumed  (such  as  in  a  function’s  argument)  they  can  never  actually  be  introduced  as 
values. 

Type  System  To  enable  automatic  threading  of  resources,  we  use  a  type-and-effect  system  with 
judgments  of  the  form:  Y  \  A()  h  e  :  A  h  Aj  stating  that  with  lexical  environment  T  and  linear 
resources  A0  we  assign  the  expression  e  the  type  A,  with  effects  resulting  in  the  resources  in  Ai. 
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The  typing  environments  are  defined  as  follows: 


=  . 

(empty)  A 

;;=  • 

(empty) 

1  r, 

x  :  A 

(variable  binding) 

|  A,  x  :  A 

(linear  binding) 

1  r, 

p  :  loc 

(location  assertion) 

1  A,  A 

(linear  resource) 

1  r, 

X<:A 

(bound  assertion) 

1  r, 

X  :  k 

(kind  assertion)  k 

::=  type  |  type  - 

a  k  |  loc  — »  k  (kinds) 

Recursive  type  variables  are  given  an  — »  kind,  where  the  left  hand  side  tracks  the  type/location 
kind  of  a  parameter  of  that  recursive  type. 

Fig.  4  includes  a  few  selected  typing  rules.  Additional  rules  are  shown  below  as  they  become 
relevant  to  the  discussion  on  sharing,  with  the  remainder  left  to  the  appendix.  (t:Pure)  types 
a  value  as  pure  if  the  value  does  not  use  any  resources.  If  a  variable  is  of  a  pure  type,  then 
(t:PureElim)  allows  the  binding  to  be  moved  to  the  linear  context  with  its  type  explicitly  “banged” 
with  !.  (t:Frame)  enables  framing  [30]  resources  that  are  not  used  by  an  expression,  just  threaded 
through  the  expression.  Since  a  function,  (t:Function),  can  depend  on  the  resources  inside  of  A 
(which  the  function  captures),  a  functional  value  must  be  linear.  However,  the  function  can  later 
be  rendered  pure  (!)  through  the  use  of  (t:Pure)  if  the  set  of  resources  it  captures  is  actually  empty. 
(t: Application)  is  the  standard  rule.  As  discussed  above,  (t:New)  and  (t:Delete)  manipulate  types 
that  abstract  the  underlying  location  that  was  created  or  that  is  to  be  deleted.  (t:Assign)  updates 
the  contents  of  a  location  with  the  type  of  the  newly  assigned  value.  (t:Let)  threads  the  effects 
of  eo  to  the  initial  linear  resources  of  e\,  sequencing  the  evaluation  of  the  expressions  as  usual. 
(t:  Dereference-Linear)  removes  the  contents  of  a  cell,  leaving  the  residual  “unit”  type  behind  (the 
semantics  leave  the  cell  unchanged  but  unusable  through  typing).  (t:LocOpenBind)  illustrates  the 
non- syntax-directed  opening  of  existential  location  packages. 

The  subtyping  rules  are  deferred  to  the  appendix,  but  it  suffices  to  know  the  subtyping  judg¬ 
ment,  T  h  Aq  <:  A\,  which  states  that  A0  is  a  subtype  of  A\,  meaning  that  A0  can  be  used  any¬ 
where  A  i  is  expected.  An  analogous  judgment  governs  subtyping  between  linear  environments, 
T  h  Ao  <:  Ai.  Thus,  the  (t: Subsumption)  rule  simply  states  that  we  can  type  an  expression  while 
using  weaker  assumptions  and  ensuring  a  stronger  result  and  effect,  as  these  types  cannot  break 
the  conclusion’s  types  expectations. 

2  A  Protocol  for  Modeling  join 

We  begin  by  describing  how  non- abstracted  protocols  compose  and  how  rely-guarantee  protocols 
work  in  the  concurrent  setting.  Our  language  supports  the  fork/join  model  of  concurrency,  in  which 
a  join  is  encoded  via  shared  state  interactions.  There  are  two  participants  in  this  interaction:  the 
Main  thread  and  the  Forked  thread.  The  forked  thread  computes  some  result.  When  the  main  thread 
joins  the  forked  thread  it  will  wait  until  the  result  becomes  available,  if  it  is  not  yet  ready.  Our 
primitives  to  interact  with  shared  state  are  reading/writing  and  locking/unlocking.  Because  of  this, 
our  protocols  must  explicitly  model  the  “wait  for  result”  cycle  of  a  join.  A  thread  scheduler  could 

3Each  protocol  must  be  aware  of  all  valid  states,  as  an  omission  would  leave  room  for  unsafe  interference,  such  as 
when  later  re-splitting  that  protocol. 
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reduce  or  eliminate  the  spinning  caused  by  this  “busy-wait”,  but  this  is  beyond  the  scope  of  our 
discussion.  We  define  the  two  protocols  as  follows: 

F  =  Wait  =>  Result ;  none 

M  =  ( Wait  =>  Wait ;  M )  ©  ( Result  =>  Done  ;  Done ) 

Each  protocol  contains  a  sequence  of  steps  that  control  the  use  of  locks  and  specify  the  (type) 
assumptions  on  that  locked  state.  Since  locks  hide  all  private  actions,  the  protocols  will  only  need 
to  model  the  changes  that  become  visible  upon  unlocking.  These  changes  are  bounded  by  a  single 
lock-unlock  block,  which  is  mapped  to  a  single  rely=>guarantee  step  in  the  protocol.  When  we 
lock  a  cell  we  will  assume  that  the  state  is  of  some  type  and,  when  we  eventually  unlock  that  cell, 
we  will  guarantee  that  it  changed  to  some  other  type.  Multiple  steps  can  be  sequenced  using  the  ; 
operator. 

The  forked  thread  will  be  given  the  F  protocol.  This  protocol  initially  assumes  that  the  shared 
state  is  of  type  Wait  on  locking.  In  order  to  legally  unlock  that  cell,  we  must  first  fulfill  the 
obligation  to  mutate  the  state  to  Result.  Once  that  guarantee  is  obeyed  the  protocol  continues  as 
none.  This  empty  resource  type  models  termination  since  the  forked  thread  will  never  be  able  to 
access  that  shared  state  again.  Note  that  since  subsequent  steps  may  be  influenced  by  the  guarantee 
of  the  current  step,  a  protocol  step  is  to  be  interpreted  as  “Wait  =>  (  Result ;  none )”. 

The  Main  protocol  includes  two  alternative  (©)  steps  that  describe  different  uses  of  the  shared 
state.  If  we  find  the  shared  cell  containing  the  Wait  type  then  the  main  thread  must  leave  the  state 
with  the  same  type,  before  later  retrying  M.  Otherwise,  if  we  find  the  cell  containing  a  Result,  we 
know  that  F  has  already  terminated  and  can  no  longer  access  the  shared  state.  In  that  situation,  we 
mutate  the  cell  to  Done  and  unlock  it  so  that  each  lock  always  has  a  matching  unlock.  Afterwards, 
the  protocol  continues  as  Done,  a  type  that  is  just  a  regular  linear  capability.  Thus,  M  recovered 
ownership  of  the  shared  state  and  Done  can  continue  to  be  used  without  locking  since  the  cell 
is  no  longer  shared.  We  can  now  give  concrete  definitions  for  Wait,  Result,  and  Done  as  types 
describing  a  single  capability  to  location  /  as  follows: 

Wait  =  rw/Wait#![]  Result  =  rw /Result#int  Done  =  rw/![] 

Wait  is  a  capability  to  location  /  containing  a  tagged  value,  where  Wait  is  the  tag  and  “![]”  (a  pure 
empty  record)  is  the  type  of  the  value.  Result  is  a  capability  for  l  containing  an  integer  value  tagged 
with  Result.  The  two  tags  will  enable  us  to  distinguish  between  the  Wait  and  Result  alternatives 
by  using  standard  case  analysis.  With  Done  the  content  is  an  empty  pure  record  (“unit”). 

Each  protocol  describes  an  alias’s  local,  isolated  view  of  the  evolution  of  the  shared  state.  Thus, 
we  can  discuss  the  uses  of  each  protocol  independently.  Because  a  protocol  is  a  linear  resource, 
the  forked  thread  will  “consume”  or  “capture”  F  in  its  context,  making  it  unavailable  to  the  main 
thread.  As  with  any  linear  resource,  F  is  tracked  by  the  linear  typing  environment  (A)  and  is  either 
used  by  an  expression  or  threaded  through  to  the  next  expression.  However,  the  forked  thread 
and  main  thread  can  share  the  enclosing  lexical  typing  environment  (T)  because  it  only  contains 
pure/duplicable  assumptions.  A  possible  use  of  the  F  protocol  follows. 

3  fork  T  =  c  :  ref  1,1  :  loc  |  A  =  work  : ![]  -<3  int,  F 

4  let  r  =  work  {}  in  T  =  r  :  int,...  |  A  =  Wait  =>  (Result;  none) 
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lock  c; 

r  =  ... 

I  A  =  Wait,  (Result ;  none) 

c  :=  Result#r; 

r  -  ... 

I  A  =  Result, (Result;  none) 

unlock  c 

r  = ... 

|  A  =  none 

end 

r  = ... 

1  A  =  - 

T  contains  a  reference  (c)  to  the  location  (/)  that  is  being  shared  by  the  protocol,  and  A  contains  a 
variable  with  the  (linear)  function  that  computes  the  work  that  the  thread  will  do.  (In  this  example 
both  protocols  refer  to  a  well-known  common  location,  but  our  technique  also  allows  each  protocol 
to  3  abstract  its  locations.)  Line  4  consumes  the  function  work  by  calling  it,  storing  the  result  in 
variable  r.  At  this  point  we  want  to  update  the  shared  state  to  signal  that  the  result  is  ready.  Since 
we  are  accessing  shared  state  in  a  multi-threaded  environment  we  first  lock  the  shared  location 
that  is  being  referenced  by  c.  To  type  a  lock  we  must  map  the  locations  listed  in  the  lock  to  those 
contained  in  the  rely  type  of  the  protocol.  Well-formedness  conditions  on  the  protocols  ensure  that, 
at  each  step,  the  rely  and  the  guarantee  types  refer  the  same  set  of  locations  so  that  no  lock  on  a 
location  goes  without  a  respective  unlock. 


T  |  •  h  v  :  ref  p  -\  •  locs(A0)  =  p 

- = - (t:Lock-Rely) 

T  |  A,  Aq  A[  h  lock  v  :  ![]  H  A,  Aq,A[ 

When  locking  (line  5),  the  step  of  F  is  broken  down  into  its  two  components:  the  rely  type  (Wait) 
and  the  guarantee  type  (Result;  none).  While  Wait  describes  the  linear  resources  that  are  now 
available  to  use,  the  guarantee  type  is  an  obligation  to  mutate  the  state  to  fulfill  the  given  type 
before  unlocking.  Indeed,  line  7  is  only  valid  because  the  shared  state  was  modified  to  match  the 
promised  guarantee  type  (Result). 


T  |  •  h  v  :  ref  p  H  •  locs(A0)  =  p 

- = -  (t:  Unlock-Guarantee) 

T  |  A,  A0,(A0;Ai)  h  unlock  v  :  ![]  H  A,A{ 


(with  parenthesis  used  for  clarity).  Once  the  guarantee  is  fulfilled,  we  can  move  on  to  the  next 
step  of  the  protocol  (in  the  case  of  F,  none;  or  A i,  in  the  case  of  the  rule  above).  The  none  type 
is  the  empty  resource  that  can  be  automatically  discarded,  leaving  A  empty  (■).  Thus,  the  uses  of 
protocols  are  mapped  to  the  (t:Lock-Rely)  and  (t:Unlock-Guarantee)  rules  that  step  a  protocol. 


We  now  show  the  rest  of  the  encoding: 

let  newFork  =  dwork. 

r  =  • 

|  A  =  work  :![]-«  int 

let  c  =  new  Wait#{}  in 

T  -  c  :  ref  /,  1 :  loc 

|  A  =  rw  /  Wai t#! [],  .. 

fork  ...  II  lines  3  to  8  shown  above. 

r  =  ... 

|  A  =  M,  F,  ... 

To  simplify  the  presentation,  our  term  language  is  stripped  of  type  annotations.  However,  the 
newFork  function  has  type  !(( ![]  int )  -o  ( ![]  -o  int))  where  the  argument  of  this  pure 
function  is  the  work  to  be  done  by  the  thread,  as  was  shown  above.  The  resulting  function  is  the 
join  (shown  below)  that,  once  called,  waits  for  the  forked  thread’s  result.  Line  2  creates  the  cell 
that  will  be  shared  by  the  main  and  forked  threads.  This  new  cell,  although  typed  3 /.(  (!ref  / )  :: 
(rw  /  Wait#![]) ),  is  automatically  opened  by  the  type  system  via  (t:LocOpenBind)  to  allow  direct 
access  to  the  ref  1  reference  via  variable  c. 
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Line  3  shares  the  cell  by  splitting  the  capability  to  location  l  into  the  M  and  F  protocols.  This 
split  is  done  in  a  non- syntax-directed  way  through  (t:Subsumption)  (of  Fig.  4),  combined  with  the 
following  rule  for  subtyping  on  A’s: 


r  i-  Ao  <:  Ai  r  i-  A(j  ^  A\  ||  A2 
- (sd:Share) 

r  t-  A 0,A0  <:  A1,A1,A2 


Where  the  following  resource  split  (^>)  is  used: 

T  h  Wait  M  ||  F  (recall:  Wait  A  rw/Wait#![]) 

This  split  results  in  the  capability  to  location  /  being  replaced  by  the  two  protocols,  M  and  F,  in 
A.  The  composition  check  (described  in  the  next  subsection)  relies  on  the  knowledge  that  M  and 
F  share  the  same  location.  Once  the  protocols  are  known  to  compose  safely,  however,  we  no 
longer  need  to  track  this  sharing — each  protocol  can  abstract  the  location  being  accessed  under  a 
different  name,  and  they  can  be  used  independently.  The  fork  expression  is  typed  by  consuming 
the  resources  that  the  fork  will  use  (such  as  F  in  the  fork  of  line  3): 

T|  A  he:  ![]-!• 

- (t:Fork) 

T|  A  h  fork  e  :  ![]  H  • 

This  rule  is  somewhat  similar  to  (t:Function),  but  the  result  type  is  unit  because  fork  does  not 
produce  a  result.  Thus,  a  fork  is  executed  for  the  effects  it  produces  on  the  shared  state.  As  such, 
to  avoid  leaking  resources,  the  final  residual  resources  of  the  forked  expression  must  be  empty  and 
the  resulting  value  pure  (note  that  “!A  <:  ![]”). 

Finally,  we  show  the  join  function  that  will  “busy-wait”  for  the  forked  thread  to  produce  a  result. 
Its  use  of  both  recursion  and  case  analysis  should  be  straightforward  as  they  follow  standard  usage. 
The  following  text  will  focus  on  the  less  obvious  details. 
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/L.rec  R. 

A  =  ( Wait  =>  (Wait;  M) ) 

®  (  Result  =>  (Done;  Done)) 

10 

[a]  A  =  Wait  =>  (Wait;  M) 

[b]A  =  Result  =>  (Done;  Done) 

11 

lock  c; 

[a]  A  =  Wait,  (Wait;  M) 

[b]  A  =  Result,  (Done;  Done) 

12 

case  ! c  of 

[a]  A  =  rw  1  ![],  (Wait;M) 

[b]A  =  rw  l  ![],  (Done;  Done) 

13 

Wait#x  — 3  //  must  restore  linear  value 

[a]  A  =  rw  1  ![],  (Wait;M) 

14 

c  :=  Wait#x; 

[a]  A  =  Wait,  (Wait;M) 

15 

unlock  c; 

[a]  A  =  M 

16 

R  //  retries 

17 

|  Result#x  — > 

1 — 1 

o' 

1 — 1 

II 

X 

H- 

3 

rf 

|  A  =  rw  1  ![],  (Done;  Done) 

18 

unlock  c; 

[b]T  =  x  :  int, . . . 

|  A  =  rw  /  ![] 

19 

delete  c; 

[b]T  =  x  :  int, . . . 

1  A  =  - 

20  x 

21  end 

22  end 

23  end 
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We  omit  T  to  center  the  discussion  on  the  contents  of  A.  The  alternative  type  (©)  lists  a  union 
of  types  that  may  be  valid  at  that  point  in  the  program.  To  use  such  a  type,  an  expression  must 
consider  each  alternative  individually  via  (t: Alternative-Left): 

T  |  A(),A()  h  e  !  A  2  H  Aj  T  |  A0,  Ai  b  e  :  A2  H  Aj 

- (t:Alternative-Left) 

T  |  Aq,  Aq  ©  A[  h  6  !  A2  H  A] 

The  breakdown  of  ©  (line  10)  is  done  automatically  by  the  type  system.  Thus,  the  body  of  the 
recursion  must  be  typed  individually  under  each  one  of  those  alternatives,  marked  as  [a]  and  [b]. 
The  type  of  the  resource  on  each  alternative  contains  a  sum  type  that  matches  different  branches  in 
the  case  of  line  12.  Note  that  it  is  safe  for  this  sum  type  to  only  match  a  subset  of  the  branches  that 
the  case  lists.  The  remaining  branches  are  simply  ignored  when  typing  the  case  with  that  sum 
type:  _ 

r  |  A0  l-  v  :  Yii  T/#A ,•  h  A]  r  |  A 1 ,  X/  :  A,-  h  e,  :  A  h  A2  i  <  j 

-  — - (t:Case) 

T  |  A0  b  case  v  of  t  j#xj  -»  ej  end  :  A  h  A2 

This  enables  the  same  case  to  produce  different  effects,  such  as  obeying  incompatible  guarantees, 
based  solely  on  the  tagged  contents  of  v.  For  instance,  the  Result  branch  will  recover  ownership 
and  destroy  the  shared  cell  (line  19),  while  the  Wait  branch  must  restore  the  linear  value  of  that 
cell  (that  was  removed  by  the  linear  dereference  of  line  12,  that  left  “rw  / ![]”  in  A)  before  retrying. 
Although  line  19  deletes  the  cell,  we  first  unlock  the  cell  to  fulfill  the  “Done;  Done”  guarantee  of 
the  final  protocol  step. 

A  rely-guarantee  protocol  is  a  specification  of  each  lock-unlock  usage,  modeled  by  a  protocol 
type.  Therefore,  we  will  continue  the  discussion  on  interference  by  only  looking  at  the  protocols, 
while  omitting  the  actual  concrete  programs  that  use  them. 

2.1  Checking  Safe  Protocol  Composition 

We  now  introduce  our  main  contribution:  a  novel  axiomatic  definition  of  protocol  composition, 
which  is  later  extended  to  support  abstraction.  Composing  protocols  over  some  shared  state  re¬ 
quires  considering  all  possible  ways  in  which  the  use  of  these  protocols  may  be  interleaved.  Thus, 
regardless  of  the  non-deterministic  way  by  which  aliases  are  interleaved  at  run-time,  a  correct 
composition  will  ensure  that  all  possible  uses  are  safe. 

Intuitively,  a  binary  protocol  split  will  generate  an  infinite  binary  tree  representing  all  combi¬ 
nations  of  interleaved  uses  of  the  two  new  protocols.  Each  node  of  that  tree  has  two  children  based 
on  which  protocol  remains  stationary  while  the  other  is  stepped.  Since  this  tree  may  be  infinite,  we 
must  build  a  co-inductive  proof  of  safe  interference.  We  only  consider  binary  splits  when  checking 
composition  but  since  a  protocol  can  be  later  re-split,  there  is  no  limit  to  how  many  protocols  may 
share  some  state. 

The  two  protocols,  M  and  F,  shown  above  contain  a  finite  number  of  different  positions.  We 
call  a  configuration  the  combination  of  the  positions  of  each  protocol  and  the  current  type  of  the 
shared  resources.  Each  configuration  is  of  the  form: 

(  T  l-  Resources  =>  Protocol  ||  Protocol ) 
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Thus,  when  we  split  a  Wait  cell  into  protocols  M4  and  F5,  we  get  the  following  set  of  configurations 
that  simulate  the  uses  done  via  the  protocols  (seen  as  atomic  public  transitions  of  lock-unlock  uses, 
corresponding  to  the  respective  rely  and  guarantee  types): 

{  O  (  T  h  Wait  ^  M  ||  F  ) ,  ©  (  T  h  Result  ^  M  ||  none  ) , 

©  (  T  h  Done  ^  Done  ||  none  > ,  ©  <  r  b  none  ^  none  ||  none  ) } 

Configuration  ©  represents  the  initial  split  of  Wait  into  M  and  F.  Starting  from  some  configu¬ 
ration,  we  will  leave  one  of  the  protocols  stationary  while  we  simulate  a  use  of  the  shared  state  (a 
step)  with  the  remaining  protocol.  From  ©  if  we  step  M  we  will  stay  in  the  same  configuration.  If 
instead  F  is  stepped,  we  get  to  configuration  ©  that  changed  the  state  to  Result  and  terminates  the 
F  protocol.  By  continuing  to  step  M  we  have  the  two  last  configurations:  ©  where  the  last  step  of 
M  is  ready  to  recover  ownership,  and  ©  where  the  ownership  of  the  shared  resource  was  recovered 
and  all  protocols  have  terminated  (i.e.  all  resources  are  empty,  none). 

Upon  sharing,  the  ownership  of  the  shared  resources  belongs  to  all  intervening  protocols;  all 
protocols  can  access  the  shared  resources  through  locking.  Ownership  recovery  means  that  this 
ownership  is  given  back  to  one  single  protocol  and  “revoked”  from  all  remaining  protocols.  In 
our  protocols,  recovery  is  modeled  via  protocol  termination,  such  that  a  step  transitions  to  a  state 
rather  than  to  another  protocol  step.  However,  to  be  safe,  we  must  be  sure  that  this  permanent 
ownership  transfer  only  occurs  on  the  last  protocol  to  terminate,  ensuring  that  no  other  protocol 
may  accidentally  assume  that  that  shared  state  is  still  available.  The  ownership  recovery  in  © 
transfers  Done  from  the  “pool”  of  shared  resources  to  the  alias  that  uses  the  last  step  of  the  M 
protocol.  We  also  see  by  ©  that  this  stepping  consumes  both  the  shared  resource  (leaving  it  as 
none)  and  the  final  “step”  of  M  (leaving  the  protocol  position  also  as  none). 

All  protocol  configurations  shown  above  can  take  a  step.  (Even  none  can  take  a  vacuous  step 
that  remains  in  the  same  configuration  since  none  cannot  change  the  shared  resources.)  Therefore, 
each  protocol  will  always  find  an  expected  state  in  the  shared  cell  regardless  of  how  protocols  are 
interleaved — i.e.  all  interference  is  safe  since  no  configuration  is  stuck.  A  stuck  configuration 
occurs  when  at  least  one  of  the  protocols  cannot  take  a  step  with  the  current  type  of  the  shared 
resources.  For  instance,  (r  b  Result  ^  M  ||  F)  cannot  take  a  step  with  F  since  F  does  not  rely  on 
Result  in  any  of  its  available  steps.  If  such  stuck  configurations  were  allowed  to  occur,  then  a 
program  could  fault  due  to  unexpected  values  stored  in  shared  cells  or  due  to  attempts  to  access 
cells  that  were  destroyed  using  wrong  assumptions  of  ownership  recovery. 

Protocol  composition  ensures  that  a  resource,  R  (capabilities  or  protocols),  can  be  shared  (split) 
as  two  protocols,  P  and  Q,  noted:  Y  b  R  P  ||  Q.  Fig.  5  lists  the  grammatical  categories 
(for  protocols,  states  and  resources)  that  we  consider  when  composing  protocols.  As  exemplified 
above  we  use  a  set  of  configurations,  C,  to  represent  the  positions  of  each  protocol  as  we  traverse 
all  possible  interleaved  uses  of  the  two  new  protocols.  C  is  defined  as: 

C  ::=  (  T  b  R  ^  P  ||  Q  )  (configuration) 

|  C  ■  C  (configuration  union) 

4M  =  ( Wait  =>  (  Wait ;  M  ) )  ©  (  Result  =>  (  Done  ;  Done  ) ) 

5F  =  Wait  =>  (  Result ;  none ) 
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P,  Q  ::=  (rec  X{u).P)[UP\  \  X[UP]  \  P®P  \  P&P  |  none 

|  5  =>  P  |  5  ;  P  |  3 l.P  |  V/.P  |  3X  <:  A.P  |  VX  <:  A.P 

S  ::=  (recX(u).S)[U^]  \  X[U^]  \  S®S  \  S  &S  |  none  |  A*  A  \  rw  p  A 
R  ::=  P  \  S 

Note:  that  the  structure  of  allowed  protocols  is  further  restricted  via  protocol  composition,  beyond  the  syntactical 
categories  above.  Namely,  abstraction  is  only  enabled  by  the  rules  of  Section  3.3. 

Figure  5:  Grammar  restrictions  for  checking  safe  protocol  composition:  Protocols,  States,  and 
Pesources. 

Protocol  composition,  applied  via  (sd:Share),  ensures  that  all  configurations  reachable  through 
stepping  are  themselves  able  to  take  a  step,  as  follows: 

<  r  h  R  =>  P  II  Q  )  T  Co  i  >  Cl  Cl  t 

-  (wf:Split)  =  (wf:Configuration) 

TbP^pue  Cot 

Where  C  T  signals  the  divergence  of  stepping,  consistent  with  the  co-inductive  nature  of  protocol 
composition.  We  use  a  double  line,  as  in  (wf:Configuration),  to  mean  that  a  rule  is  to  be  interpreted 
co-inductively.  This  definition  accounts  for  protocols  that  never  terminate  and  also  ensures  that  all 
protocols  can  take  a  step  with  a  given  resource. 

We  now  discuss  the  basic  protocol  composition  definition  of  Fig.  6.  (c:  AllStep)  synchronously 
steps  all  existing  configurations,  where  each  configuration  is  stepped  through  (c:Step).  We  use  % 
(where  *  is  either  L  or  R)  to  specify  the  configuration  reduction  context  on  one  of  the  protocols  of 
a  configuration,  while  the  remaining  protocol  remains  stationary,  i.e.: 

RL[ □]  =  □  ||  Q  (for  the  Left  protocol,  Q  is  stationary) 

=  P  H  □  (for  the  Pight  protocol,  P  is  stationary) 

The  subsequent  stepping  rules  use  R  to  range  over  both  %L  and  RK. 

We  use  three  distinct  label  prefixes  to  group  the  stepping  rules  based  on  whether  a  rule  is 
stepping  over  a  protocol  (c-ps:*),  stepping  over  some  state  (c-ss:*),  or  is  applicable  on  both  kinds 
of  resource  (c-rs:*).  (c-rs:None)  “spins”  a  configuration  since  a  terminated  protocol  cannot  use 
the  shared  resources  but  must  be  stuck-free  for  consistency  with  our  definition.  The  following 
(c-rs:*Alternative)  and  (c-rs ^Intersection)  rules  “dissect”  a  resource  based  on  the  alternative 
(©)  or  choice  (&)  presented.  Each  different  alternative  state  must  be  individually  considered  by 
a  protocol,  while  only  one  alternative  step  of  a  protocol  needs  to  be  valid.  The  situation  is  the 
reverse  for  choices:  all  choices  of  a  protocol  must  have  a  valid  step,  but  a  step  of  a  protocol  can 
choose  which  resource  to  consider  when  stepping.  State  stepping,  (c-ss:Step),  transitions  the  step 
of  the  protocol  and  changes  the  state  of  the  shared  resources  to  reflect  the  guaranteed  state  of  the 
protocol.  Ownership  recovery,  (c-ss:Recovery),  “consumes”  the  shared  state  (leaving  it  as  none) 
which  models  the  transfer  of  ownership  of  that  state  back  to  the  client  context  that  uses  the  final 
step  of  the  protocol.  Protocol  stepping,  (c-ps:Step),  requires  an  exact  simulation  of  the  rely  and 
guarantee  types  when  stepping  both  the  simulated  protocol  and  the  current  stepping  protocol. 
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C  h-»  c 


Composition,  (c:*) 


(c:Step) 

<  r  h  R  =>  Kl[P ] )  i  ►  Co  ftL[n]  =  □  ||  Q 

<  T  h  P  ^  <Rr[Q\  )  i  >  Ci  =  P  ||  □ 


(c:AllStep) 

Co  C2 
Ci  i->  C3 


<  r  h  p  =>  p  ||  g  )  c0  •  cx 


Co  •  Ci  1— >  C2  •  C3 


(c-rs:None) 


Composition  —  Reduction  Step,  (c-rs:*) 


(  r  h  R  ^  P[none] )  i->  <  r  1-  R  ^  P[none] ) 


(c-rs:StateIntersection) 

<  r  h  p0  ^  W] )  ^  c 
(  r  h  P0&Pi  ^  P[P]  )  i-»  c 

(c-rs:ProtocolIntersection) 

<  r  h  R  ^  <R[P0]  )  Co 

<  r  h  R  ^  R[P  1]  )  Cl 

<  r  h  R  =»  P[P0&Pi]  )  ^  Co  •  Ci 


(c-ss:Step) 


(c-rs  :ProtocolAlternative) 

<  r  h  R  =>  P[P0]  )  1  >  C 
(ThP  ^P[P0®Pi]  )  i-»  C 
(c-rs:StateAlternative) 

(  r  h  P0  ^  K[P]  )  •->  Co 
<  r  h  p,  =»  R[P] )  Ci 

<rhP0®Pi  ^<R[P])^cq-c1 

Composition  —  State  Stepping,  (c-ss:*) 


<ri-5o^^[5o=>5i;P])i-><ri-5i^^[P]) 


(c-ss:Recovery) 


<  r  h  5  ^  <R[S]  )H{Th  none  =*  P[none] ) 


(c-ps:Step) 


Composition  —  Protocol  Stepping,  (c-ps:*) 


<  T  h  5  0  =>  5 1 ;  Q  =»  <R[S  0  =>  5 1 ;  P]  )  <  r  h  Q  ^  R[P]  > 


Figure  6:  Basic  protocol  composition  stepping  rules. 
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Note  that  the  rules  above  also  enable  the  re-splitting  of  a  protocol  by  extending  an  ownership 
recovery  step.  In  this  situation,  we  have  that  the  simulation  of  the  original  protocol  will  seamlessly 
switch  from  the  protocol  stepping  rules  to  the  state  stepping  rules. 


3  Polymorphic  Protocol  Composition 

Up  to  this  point,  protocol  composition  does  a  strict  stepping  of  protocols.  Consequently,  stepping 
requires  each  protocol  to  know  the  exact  type  representation  of  the  shared  resources.  Ideally,  to 
improve  both  locality  and  modularity,  each  protocol  should  only  depend  on  the  type  information 
that  is  relevant  to  the  actions  done  through  that  alias.  For  instance,  the  action  done  through  the  F 
protocol  of  page  9  does  not  need  to  know  the  precise  type  (Wait)  that  is  initially  stored  in  location 
/.  Thus,  we  want  to  be  able  to  abstract  Wait  as  X  such  that  the  protocol  only  keeps  the  typing 
information  that  is  relevant  to  that  protocol’s  local  perspective  on  the  shared  resources: 

3X.(  rw  IX  =>  (  rw  l  Result#int  ;  none  )  ) 

Similarly,  the  wait  step  of  the  M  protocol  only  depends  on  the  tag  of  the  shared  cell  enabling 
everything  else  to  be  abstracted  from  its  perspective: 

3X(  rw  /  Wait#X  =>  (  rw  /  Wait#X  ;  M  )  )  ©  ... 

Since  rely-guarantee  protocols  are  first-class  types,  they  can  move  outside  the  scope  of  a  “mod¬ 
ule”.  Without  this  form  of  abstraction,  such  a  move  would  either  expose  potentially  private  infor¬ 
mation  or  limit  how  clients  may  later  re- split  the  shared  resources.  While  enabling  protocols  to 
abstract  part  of  their  uses  based  on  their  perspective  of  the  shared  resources  improves  modularity 
and  increases  flexibility,  it  also  brings  new  challenges  on  defining  safe  protocol  composition  and 
ensuring  its  termination.  We  will  focus  the  discussion  on  two  new  aliasing  idioms  that  this  kind 
of  abstraction  enables:  a)  existential-universal  interaction ,  how  a  universally  quantified  guarantee 
can  safely  interact  with  an  existentially  quantified  rely;  and  b)  step  extensions  over  abstractions , 
how  abstractions  enable  existing  protocol  steps  to  be  re-split  (i.e.  nested  protocol  re-splitting)  yet 
without  the  risk  of  introducing  unsafe  interference  on  older  protocols  of  that  state. 

Section  4  approaches  the  decidability  problem.  The  remaining  of  this  section  starts  by  intro¬ 
ducing  the  basic  intuition  of  how  protocol-level  abstraction  works,  before  extending  our  axiomatic 
definition  of  composition  to  account  for  abstraction. 

3.1  Existential-Universal  Interaction 

Enabling  existential  abstraction  over  the  contents  of  the  shared  state  will  naturally  allow  a  greater 
decoupling  from  the  actions  done  by  other  aliases  to  that  shared  state.  However,  since  a  protocol 
encodes  sequences  of  steps,  ensuring  safety  must  also  account  for  the  validity  of  the  scope  of  the 
opaque  type.  For  instance,  consider  the  composition: 

T  h  rw  p  int  ^  3X.(  rw  p  X  =>  rw  p  X ;  rw  p  X  =>  ... )  ||  ( rw  p  int  =>  rw  p  boolean  ;  ... ) 
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On  the  left  protocol,  the  assumption  of  X  extends  beyond  a  single  step.  Because  the  right  protocol 
can  change  the  underlying  representation  of  X,  this  composition  cannot  be  ruled  safe.  Indeed,  if 
X  were  of  a  pure  type,  the  left  protocol  could  potentially  reintroduce  a  type  that  would  unsafely 
interfere  with  the  right  protocol’s  assumptions  on  the  shared  state.  Thus,  while  the  left  protocol 
depends  on  an  opaque  type,  it  still  requires  that  the  “lifetime”  of  X  extends  to  the  next  step. 

We  now  discuss  the  core  ideas  that  enable  the  safe  composition  of  protocols  that  interact  over 
abstractions.  First  the  interaction  will  only  occur  via  the  “lifetime”  of  the  stored  type  (as  it  changes 
on  each  step),  and  then  we  will  use  bounded  quantification  to  enable  types  that  are  less  opaque. 
Consider  the  following  protocols  that  are  sharing  a  location  p: 

Nothing  =  3A.(  rw  p  X  =>  rw  p  X  ;  Nothing  ) 

Full[T]  =  rwpF=>  VZ.(  rwpZ;  Full[Z]  ) 

The  Nothing  protocol  is  defined  using  X  to  abstract  the  contents  of  the  shared  cell  on  a  single  step, 
while  also  guaranteeing  that  X  is  restored  before  repeating  the  protocol.  Thus,  Nothing  cannot 
publicly  modify  the  shared  state,  although  p  can  undergo  private  changes.  Conversely,  Full  is 
able  to  arbitrarily  modify  the  shared  state  by  allowing  its  clients  to  pick  any  type  to  apply  to  the 
V  of  the  guarantee.  Full  itself  is  parametric  on  the  type  that  is  currently  stored  in  the  shared  cell, 
Y.  Each  step  of  Full  can  exploit  the  precise  local  information  on  how  the  state  was  modified, 
by  remembering  its  own  changes  to  cell  p.  However,  the  “lifetime”  of  X  in  Nothing  is  restricted 
to  a  single  step.  Naturally,  to  be  able  to  check  this  composition  in  a  finite  number  of  steps,  we 
must  check  the  changes  done  by  Full  abstractly.  To  illustrate  how  composition  works  in  this  case, 
consider  the  following  split  where  p  initially  holds  a  value  of  type  int: 

p  :  loc  h  rw  p  int  ^  Full[int]  ||  Nothing 
Protocol  composition  results  in  the  following  set  of  configurations: 

{ O  (p  :  loc  h  rw  p  int  ^  Full[int]  ||  Nothing  ) , 

©  (p  :  loc,  Z  :  type  l-  rw  p  Z  ^  Full[Z]  ||  Nothing  )  } 

The  use  of  abstraction  will  mean  that  each  configuration  may  have  different  assumptions  of  type 
(and  location)  variables.  Configuration  O  is  the  initial  configuration  given  by  the  split  above, 
which  includes  the  assumption  that  p  is  a  known  location.  To  step  Nothing  from  O,  we  must  first 
find  a  representation  type  to  open  the  existential.  This  type  is  found  by  unifying  the  current  state 
of  the  shared  state  (rw  p  int)  with  the  rely  type  of  Nothing  (rw  p  X).  Thus,  we  see  that  X  is 
abstracting  int.  After  we  open  the  existential,  by  exposing  the  int  type,  we  see  that  the  step  will 
preserve  int  resulting  in  Nothing  yielding  the  same  ©  configuration.  To  step  ©  with  Full[int], 
we  must  consider  that  its  resulting  guarantee  is  abstract.  The  new  configuration,  ©,  must  consider 
a  fresh  type  variable  to  represent  that  new  type  that  a  client  can  pick.  In  this  case,  we  used  Z 
to  represent  that  new  type.  It  is  straightforward  to  see  that  if  we  were  to  step  Nothing  from  © 
we  would  remain  in  configuration  ©  following  similar  reasoning  to  that  done  for  ©.  Perhaps  the 
surprising  aspect  is  that  further  steps  with  Full  will  also  yield  configurations  that  are  equivalent 
to  ©. 
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The  typing  environment  plays  a  crucial  role  in  enabling  us  to  close  the  proof  of  safe  compo¬ 
sition.  Although  each  step  of  Full  must  consider  a  fresh  type  due  to  the  V,  stepping  results  in 
configurations  that  are  equivalent  up  to  renaming  of  variables  and  weakening  of  T.  Weakening 
allows  us  to  ignore  variables  that  no  longer  occur  free  in  a  configuration.  This  means  that  further 
steps  with  Full  result  in  configurations  that  are  equivalent  to  already  seen  configurations.  Thus, 
although  the  set  of  different  types  that  can  be  applied  to  Full’s  guarantee  is  infinite,  the  number 
of  distinct  interactions  that  can  legally  occur  through  that  shared  state  is  finite  if  we  model  those 
interactions  abstractly.  Lifetime  conflicts  cannot  occur  with  this  technique  as  even  if  we  open  an 
existential,  we  must  still  step  the  new  configuration.  Consequently,  the  problematic  composition 
above  would  be  detected  via  stepping. 

We  can  use  bounded  quantification  to  provide  more  expressive  abstractions  that  go  beyond  the 
fully  opaque  types  used  above  (which  are  equivalent  to  a  “<:  top”  bound),  and  convert  this  ex¬ 
ample  into  one  of  more  practical  use.  By  using  appropriate  bounds,  we  can  give  concrete  roles  to 
the  Nothing  and  Full  protocols.  Consider  that  we  want  to  share  access  to  some  data  structure 
among  several  different  threads.  However,  depending  on  how  these  threads  dynamically  use  that 
data  structure,  it  may  become  important  to  switch  its  representation  (such  as  change  from  a  linked 
list  to  a  binary  tree,  etc.).  Furthermore,  we  want  one  specialized  thread  (the  Controller)  to  retain 
precise  control  over  the  data  structure  and  to  be  allowed  to  monitor  and  change  its  representa¬ 
tion.  Concurrently,  an  arbitrary  number  of  other  threads  (the  Workers)  also  have  access  to  the  data 
structure  but  are  limited  to  only  access  its  Basic  operations. 

W  =  3X  <:  B.(  rw  p  X  =>  rw  p  X  ;  W ) 

C|T]  =  rw  p  Y  =>  VZ  <:  B.(  rwpZ;  C[Z]  ) 

As  before  W  is  committed  to  preserve  the  representation  type  of  X  although  it  now  has  sufficient 
room  to  use  that  type  as  B.  C  is  now  more  constrained  than  before  since  it  is  forced  to  guarantee 
a  type  that  is  compatible  with  B.  However,  C  retains  the  possibility  of  both  changing  the  represen¬ 
tation  type  contained  in  the  shared  state,  and  also  of  “remembering”  the  precise  (representation) 
type  that  was  the  result  of  its  own  local  action.  Finally,  note  that  we  can  safely  re-split  W  arbitrarily 
(i.e.  W  ^  W  ||  W).  Protocol  composition  yields  similar  set  of  configurations,  but  with  the  bound 
assumption  on  Z. 

This  form  of  asymmetric  interaction  over  shared  state  relates  to  the  full  -  pure  interaction 
of  access  permissions  [4],  A  full  permission  allows  exclusive  write  permission  to  an  object, 
but  also  enables  read-only  permissions  (pure)  to  co-exists.  Consequently,  each  pure  permission 
must  assume  that  other  permissions  can  modify  the  shared  object  up  to  a  certain  type,  the  state 
guarantee.  While  their  work  focuses  on  the  read-write  distinction,  and  our  work  is  centered  on 
modeling  type-changing  mutations  (so  all  aliases  can  write),  the  example  shows  that  we  are  able 
to  naturally  model  similar  asymmetric  interaction  within  our  protocol  framework. 

3.2  Inner  Step  Extension  with  Specialization 

Re-splitting  an  existing  protocol  while  specializing  its  interference  is  possible,  provided  that  its 
effects  remain  consistent  with  those  of  the  original  protocol.  Namely  we  can  append  new  steps  to 
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an  otherwise  ownership  recovery  step,  or  produce  effects  that  are  more  precise  than  those  of  the 
original  protocol.  The  first  case  allows  us  to  connect  two  protocols  together  by  that  recovery  step. 
The  latter  case  is  more  interesting:  when  combined  with  abstraction  it  allows  specialization  within 
an  existing  step  (i.e.  nested  re-splits),  enabling  new  forms  of  shared  state  interaction  through  that 
abstraction. 

To  illustrate  the  expressiveness  gains,  we  revisit  the  join  protocol  of  Section  2.  However, 
instead  of  spawning  a  single  thread  to  compute  the  work,  we  re-split  the  join  protocol  in  two 
symmetric  workers  that  share  the  workload.  The  last  of  the  workers  to  complete  merges  the  two 
results  together  and  “signals”  the  waiting  main  thread.  First,  we  rewrite  the  two  protocols  to  enable 
abstraction  on  the  M  protocol,  and  add  a  choice  (&)  to  the  F  protocol  that  enables  F  to  use  the  state 
more  than  once  until  it  provides  a  result. 

F[X]  =  (  rw  p  W#X  =>  VY.(  rw  p  WY  ;  F[T] ) )  &  (  rw  p  WX  =>  rw  p  R#int ;  none  ) 

M  =  3 Z.(  rw  p  W#Z  =>  rw  p  W#Z  ;  M  )  ©  (  rw  p  R#int  =>  rw  p  int ;  rw  p  int ) 

As  before,  M  will  Wait  until  there  is  a  Result  in  p.  At  that  point,  M  will  recover  ownership  of  that 
cell.  Unlike  before,  M  no  longer  depends  on  the  value  tagged  as  W  since  it  is  abstracted  as  Z.  The 
F  protocol  now  holds  two  choices  (&):  the  old  step  that  transitions  from  Wait  to  Result,  and  a  new 
step  that  changes  the  representation  of  the  value  tagged  as  W  and  used  during  the  wait  phase.  The 
F  protocol  of  Section  2  is  a  specialization  of  this  protocol  since  it  includes  only  one  of  the  choices. 
In  here,  we  specialize  F  into  two  symmetric  worker  protocols.  To  simplify  the  presentation,  we 
assume  that  the  worker  thread  will  receive  the  work  parameters  through  some  other  mean  (such  as 
a  pure  value  shared  among  threads).  Once  a  worker  finishes  its  job,  it  will  push  the  resulting  int 
to  the  shared  state.  If  it  notices  it  is  the  last  worker  to  finish,  it  will  merge  the  two  results  together 
and  flag  the  state  as  ready,  so  that  Main  can  proceed. 

K  =  (  rw  p  W#(E#[])  =>  rw  p  W#(R#int) ;  none )  ©  ( rw  p  W#(R#int)  =>  rw  p  R#int ;  none  ) 

It  is  important  to  note  that  the  new  tags/values  are  nested  inside  the  old  W  tag.  This  ensures  that 
the  new  usages  remain  hidden  from  M  and  “look”  just  like  the  previous  F  usage.  (There  are  also 
no  lifetime  conflicts  since  M  does  not  preserve  its  type  assumption  on  the  abstraction  beyond  a 
single  step.)  However,  these  inner  tags  are  used  by  the  two  workers  for  coordination:  the  W#Empty 
tag  means  that  neither  thread  has  finished,  and  W#Result  means  that  one  of  the  threads  has  already 
finished.  We  can  then  re-split  F  as  follows  (note  the  required  initial  type  in  F,  E#[],  for  this  split  to 
be  valid): 

T  h  F[E#[]]  ^  K  ||  K 

Protocol  composition  follows  analogous  principles  to  above,  except  that  we  are  now  simulating  the 
steps  of  the  original  F  protocol  with  the  steps  of  the  two  new  K  protocols: 

{  (  T  h  F[E#[]]  ^  K  II  K  ) ,  <  T  h  F[R#int]  K  ||  none  ) , 

(  T  h  F[R#int]  ^  none  ||  K  ) ,  (Tt  none  ^  none  ||  none  )  } 

Each  simulation  will  match  the  rely  and  guarantee  types  of  a  step  in  F  with  a  step  in  K,  even 

if  specializing  a  V  of  F  to  a  specific  type  in  K.  As  before,  K  can  choose  which  step  to  simulate 
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(c-rs  :  Weakening) 

<  r0  h  R  ^  K[P]  )  h->  c 

<r0,ri  h r^K[p])^c 


(c-ss:ForallLoc) 

<  T,  /  :  loc  h  5  =>  <R[S  =>  P]  )  h->  C 
<  T  h  S  =»  <R[S  =>  V/.P]  )  i->  C 


(c-ss:OpenLoc) 

<  r  h  5  =»  mPip/i}] )  i-»  c 

<  r  h  S  =>  K[31.P]  )  i->  c 


(c-ss:ForallType) 

<  F,X  :  type,  X  <:  A  h  5  =>  <R[S  =>  P]  >  i->  C 
<  T  h  5  =»  P[S  =>  VX  <:  A.P]  )  i->  C 


(c-ss:OpenType) 

ThAiCAo  (ThS  ^^[PfAi/X}]  )  h->  C 


<  r  h  S  =>  <R[3X  <:  A0.P]  )  i->  C 


(c-ps:ExistsType) 

<  T,X  :  type,  X  <:  A  h  P  ^  ??[£]  )  i-*  C 

<  T  h  3A  <:  A.P  =>  P[3A  <:  A.Q]  )  i->  C 


(c-ps:ExistsLoc) 

<  T,  /  :  loc  h  P  =>  P[£]  )  i — >  C 

<  r  h  3/.P  =>  7?[3/.£]  )  !->  c 


(c-ps:ForallType) 

<  T,X  :  type, X  <:  A  h  5  =>  P  =>  <R[S  =>  2]  )  i-»  C 
(  r  h  5  =>  VX  <:  A.P  ^  K[S  =>  VZ  <:  A.Q]  )  i->  C 

(c-ps:ForallLoc)  (c-ps:LocApp) 

<  T,  /  :  loc  h  5  =>  P  =>  ft[S  =>  2]  )  >-»  C  <  T  h  5  =>  P{p/l}  ^K[S  =>  j21  )  •-»  C 

<  r  h  5  =>  v/.p  =>  p[5  =>  vz.g] )  i — ►  c  <  r  h  s  =>  v/.p  =>  p[s  =>  2]  >  i->  c 

(c-ps:TypeApp) 

ThAjcAo  <Th5  PfAj/X]  ^  P[S  =>  0]  )  •-»  C 
<  T  h  5  =>  VX  <:  A0.P  ^  P[5  =>  Q]  )  i->  C 


P{A/A)  =  “substitution,  in  P,  of  A  for  A” 

Note:  bound  type/location  variables  of  a  type  must  be  fresh  in  that  rule’s  conclusion. 


Figure  7:  Protocol  composition  abstraction  extension. 


when  given  a  choice  (&)  of  F  steps.  Similarly,  at  least  one  alternative  (©)  of  K  must  match  a  step 
in  F.  Therefore,  the  new  K  protocols  work  within  the  interference  of  the  original  F  protocol,  but 
specialize  its  uses  of  the  shared  state. 

3.3  Composing  Abstract  Protocols 

The  composition  rules  of  Fig.  29  complement  those  of  Fig.  6  to  enable  composing  abstract  proto¬ 
cols.  Weakening  on  a  configuration  (up  to  renaming),  (c-rs:Weakening),  is  the  crucial  mechanism 
that  enables  us  to  close  the  co-inductive  proof  when  using  quantifiers.  Thus,  when  we  reach  a 
configuration  that  is  equivalent  up  to  renaming  of  variables  and  weakening  of  T,  we  can  close  the 
proof.  The  (c-ss:Forall*)  rules  do  similar  stepping  to  (c-ss:Step)  but  considering  an  abstracted 
guarantee,  which  results  in  a  typing  environment  with  the  opened  abstraction.  (c-ss:Open*)  ex- 
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poses  the  representation  type/location  (if  it  exists)  before  doing  a  regular  step.  (c-ps:Forall*)  and 
(c-ps:Exists*)  open  their  respective  abstraction  before  doing  a  regular  simulation  step.  More  inter¬ 
estingly,  (c-ps:*App)  enables  a  simulated  step  to  pick  a  particular  type/location  to  apply  before  that 
regular  simulation  stepping,  enabling  step  specialization  during  simulation.  In  the  T.R,  we  also 
consider  a  straightforward  extension  to  protocol  composition  that  enables  subtyping  over  stepping. 

3.4  Discussion  &  Brief  Examples 

Above,  we  showed  how  our  local,  isolated  protocol  types  can  model  core  interference  concepts 
over  a  relatively  small  and  simple  calculus.  We  refrained  from  adding  support  for  more  precise 
states  and  refined  data  abstractions  of  others  (such  as  [18]),  and  focus  instead  on  typestates  [22,  33, 
34].  However,  this  is  not  an  intrinsic  limitation  of  our  model.  If  we  consider  more  precise  states, 
we  can  (for  instance)  model  monotonic  counters  from  prior  work  [28,  14]  where  each  counter 
shares  state  symmetrically.  Our  local  protocols  model  these  uses  solely  from  the  perspective  of  a 
single  alias  as: 

MC  =  3 {  /  ;  int]  .(rwp  j  =>  V {i :  int  |  i  >  j) .(  rw  p  ;  MC  ) ) 

j  j  i  1 

The  protocol  models  a  monotonically  increasing  counter  on  location  p.  The  step  relies  on  location 
p  initially  containing  some  integer,  /,  and  modifying  the  cell  to  store  some  other  value,  i,  that  is 
greater  or  equal  than  j.  This  interaction  can  be  reduced  to  the  core  existential-universal  protocol 
interaction  discussed  above  (but,  in  our  calculus,  using  less  precise  types:  J  and  I)  and  where  the 
protocol  can  be  re-split  indefinitely. 

While  our  states  are  less  precise,  we  can  enforce  more  precise  uses  of  that  shared  state.  The 
semantics  of  prior  work  [28,  14]  differed  on  whether  the  counter  was  forcefully  used  by  clients,  or 
whether  the  action  was  simply  available  to  be  used.  We  can  model  the  two  cases  explicitly: 

3p.{  (!ref  p)  ::  MC  -o  []  ::  MC  ) 

Enables  clients  to  use  the  counter  an  arbitrary  number  of  times  or  simply  thread  it  through,  unused. 

VX.3 p.{  (!ref  p)  ::  3J.(  rw  p  J  =*  V/.(  rw  p  I ;  A  ) )  -o  []  ::  A  ) 

By  unfolding  the  protocol,  the  function  guarantees  that  a  single  step  of  the  protocol  will  be  used. 
Since  we  (intentionally)  abstract  subsequent  steps,  the  function  cannot  use  the  counter  beyond  that 
single  use.  Analogous  reasoning  can  be  used  to  enforce  specific,  finite,  usages. 

Adding  support  for  dependent  refinement  types,  and  ensuring  its  decidability  (even  without 
interference),  is  beyond  the  scope  of  our  work  as  we  focus  on  the  core  composition  problem. 
However,  we  believe  that  the  underlying  decidability  insights  made  here  will  carry  to  a  system 
with  decidable  dependent  refinement  types;  even  if  perhaps  requiring  more  fine-grained  conditions 
to  close  the  co-inductive  proof  of  safe  interference — that  are  only  relevant  once  more  precise  typing 
is  considered. 

While  we  use  a  relatively  simple  calculus  to  keep  the  theory  focused  on  the  core  of  interference- 
control,  we  can  for  instance  model  MVars  [25].  Fig.  8  shows  an  MVar,  a  structure  that  contains 
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let  newMVar  =  A 
let  m  =  new  Empty#{}  in 
//  “shares”  the  new  cell  using  MVar  protocol 

r  h  (rw  1  Empty#[])  ^  MVar[/]  ||  none 

{ 

putMVar  =  A  val . 

rec  R. 
lock  m; 
case  !m  of 

Empty#x  — >  m  :=  Full#val; 

unlock  m 

|  Full#value  — »  m  :=  Full#value; 

unlock  m; 

R  //  retries 

end 

end, 

splitMVar  =  A 

r  h  HVar[/]  =»  MVar[/]  ||  MVar[/] 

{}, 

takeMVar  =  A 

rec  R. 
lock  m; 
case  !m  of 

Empty#x  — »  m  :=  Empty#x; 
unlock  m; 

R  //  retries 

|  Full#value  — »  m  Empty#{}; 

unlock  m; 
value 
end 
end 

} 

end 

end 


Figure  8:  MVar  example. 
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let  x  =  new  ®  in 

//  share  ’x’  as  via  some  protocols 
{ 

lockMe  =  /l_.lock  x, 

II  ... 

} 


Figure  9:  Indirect  locking. 


a  single  shared  cell  which  is  either  empty  or  contains  a  value  of  some  type.  Notable  operations 
include:  putMVar,  that  waits  until  the  cell  is  empty  before  inserting  the  given  value;  and  takeMVar 
which  waits  until  the  cell  is  full  to  remove  the  cell’s  value,  leaving  the  cell  empty.  MVars  can  be 
shared  by  many  aliases,  each  assigned  a  protocol  such  as: 

MVar[m]  =  3T(  ( (rw  m  Empty#F)  =>  (rw  m  Empty#!7)  ;  MVar[m]  )  & 

( (rw  m  Empty#!7)  =>  (rw  m  Full#int)  ;  MVar[/n]  ) ) 

©  ( ( (rw  m  Full#int)  =>  (rw  m  Empty#[])  ;  MVar[w] )  & 

3Y.(  (rw  m  Full#!7)  =>  (rw  m  Full#!7)  ;  MVar[m]  ) ) 

The  appendix  includes  additional  examples,  including  modeling  examples  of  prior  work  with 
our  more  local  protocol  types.  We  can  also  model  a  shared  pair  where  each  alias  keeps  its  own, 
local,  precise  knowledge  on  one  of  the  two  components  of  the  pair  stored  in  that  shared  state.  The 
two  aliases,  L  and  R,  share  a  common  cell  but  keep  part  of  that  state  private  to  itself.  While  both 
can  do  private  actions  over  the  shared  cell,  they  are  guaranteed  to  not  interfere  with  the  precise 
assumptions  of  the  remaining  alias. 

P[A][fi]  #  rw  p[A,B\ 

L [A]  #  3X.{  P[A][X]  =*  VT.(  P m[X]  ;  L[y]  ) )  T  h  P[X][Y]  ^  L[X]  ||  R[y] 

R[A]  #  3X.(  P[X][A]  =*  vy.(  P[X][y]  ;  R[y]  ) ) 

Thus,  we  can  use  the  different  perspectives  of  each  protocol  to  model  local  knowledge  that  is 
hidden  from  other  aliases,  within  our  core  protocol  framework  without  needing  additional  mecha¬ 
nisms. 

Since  our  types  express  sharing,  we  can  use  standard  techniques  to  abstract  the  components 
of  a  protocol  type  after  safe  composition  is  checked.  This  enables  an  abstraction  to  expose  a 
type  interface  that  indirectly  manipulates  the  shared  state,  such  as  indirectly  locking/unlocking 

state  (Fig.  9).  We  can  type  the  record  in  such  a  way  to  hide  the  type  in  x  but  still  expose  some 

information  on  sharing  that  is  useful  for  later  enabling  other  typestate  functions  [22].  For  instance: 

3A.3B.3C.[ ...,  lockMe  :  []  ::  (A  =>  B;  C)  -o  []  ::  (A  *  (B;  C)),  add  :  (  int  ::  A  -o  []  ::  A  ),  ...  ] 

Clients  can  only  call  add  once  the  type  A  is  available.  This  could  model,  for  instance,  a  global  lock 
on  a  collection  to  enable  more  coarse-grained  control  over  the  interference  to  that  collection — but 
without  exposing  the  lock  to  clients.  Thus,  when  lockMe  returns,  the  client  receives  a  type  that 
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lock  @a  ;  r  =  a  :  ref  @a 
let  b  =  ! a ; 

lock  @b;  // locks  loc.  of ’b’ 

unlock  @a; 

let  c  =  !b; 
lock  @c; 
unlock  @b; 


Figure  10:  Hand-over-hand  locking  example. 


expresses  that  A  is  available  and  that  a  guarantee  (B;  C)  is  expected  to  be  fulfilled.  However,  this 
fulfillment  can  only  occur  indirectly  via  the  wrapper  record  as  clients  do  not  have  a  direct  way  of 
accessing  or  mutating  the  internals  of  that  shared  state. 

While  we  do  not  guarantee  dead-lock  freedom,  it  is  possible  to  type  more  fine-grained  locking 
schemes  such  as  hand-over-hand  locking  (Fig.  10).  Consider  the  protocol  of  a  list’s  node: 

L[g]  =  3 /.( (rw  q  !ref  /)  *  L[Z]  =>  (rw  q  !ref  /)  ;  ... ) 

L  is  defined  over  a  location  q  that  contains  the  (abstracted)  reference  to  the  next  element  of  the 
sequence  of  /ocations  to  be  locked.  Locking  will  enable  access  to  that  ref  l  which  can  then  be 
locked  to  gain  access  to  L[/],  the  next  element  in  the  sequence  of  locations  to  lock.  For  brevity, 
we  make  each  step  simply  consume  the  L  protocol  of  the  element  in  that  sequence,  instead  of  (for 
instance)  re-splitting. 


4  Composition  Decidability  &  Other  Technical  Results 

We  now  show  decidability  of  protocol  composition  and  discuss  the  remaining  technical  results  of 
our  language.  The  decidability  statement  comes  as  a  direct  consequence  of  ensuring  a  regular  type 
structure  via  syntactic  well-formedness  constraints  on  recursive  types.  Although  applied  in  the 
context  of  protocol  composition,  we  follow  ideas  from  prior  work  on  ensuring  decidable  subtyping 
over  bounded  quantification  [32,  6].  The  main  novelty  is  in  extending  this  kind  of  reasoning 
to  account  for  recursive  types  with  parameters,  in  order  to  ensure  a  regular  type  structure  over 
our  more  flexible  recursive  types.  To  achieve  this,  we  apply  well-formedness  conditions  which 
ensure  that  there  is  only  a  finite  number  of  reachable  (abstract)  protocol  states.  We  focus  the 
discussion  on  decidability  of  protocol  composition,  and  point  interested  readers  to  appendix  where 
these  conditions  are  properly  motivated  and  discussed.  Crucially,  these  well-formedness  conditions 
enable  us  to  state  the  following: 

Lemma  1  (Finite  Uses).  Given  a  well-formed  recursive  type  ( rec  X(u).A)[U\  the  number  of  possi¬ 
ble  uses  ofX  in  A  such  that  V  b  X\  U'  \  type  is  bounded. 
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Lemma  2  (Finite  Unfolds).  Unfolding  a  well-formed  recursive  type  (i rec  X(u).A)\U\  produces  a 
finite  set  of  variants  of  that  original  recursive  type  that  (at  most )  contains:  permutations  ofU,  or  a 
set  of  mixtures  ofU  with  some  type/location  variables  representing  a  class  of  equivalent  (=)  types. 

Lemma  3  (Finite  Sub-Terms).  Given  a  well-formed  type  A,  such  that  Y  b  A  type,  the  set  of  sub - 
terms  of  A  is  finite  up  to  renaming  of  variables  and  weakening  ofT. 

4.1  Composition  Properties,  Algorithm,  and  Decidability 

Informally,  correctness  of  protocol  composition  is  based  on  the  two  properties:  1)  a  split  results  in 
protocols  that  can  always  take  a  step  with  the  current  state  of  the  shared  resources,  thus  are  never 
stuck;  and,  2)  protocol  composition  is  a  partial  commutative  monoid  (associative,  commutative, 
and  with  none  as  the  identity  element).  Because  of  property  2),  iterative  splittings  of  existing 
protocols  remain  struck-free,  unable  to  cause  unsafe  interference.  We  now  state  these  properties 
formally  but  leave  the  proofs  to  the  appendix.  The  following  two  lemmas  show  stuck  freedom  by 
properties  that  resemble  progress  and  preservation  but  over  protocols: 

Lemma  4.  IfT  b  R  =>  P  ||  Q  then  <  Y  b  R  =>  P  ||  Q  )  ^  C. 

Meaning  that  if  two  protocols,  P  and  Q,  compose  safely  then  their  configuration  can  take  a  step 
to  another  set  of  configurations,  C. 

Lemma  5.  //<  T  b  R  ^  P  ||  Q  )  b+  <  V  b  R'  ^  P'  ||  Q  )  •  C  and  Y  b  R  ^  P  ||  Q  then  F  b  R'  => 
P'  II  Q'- 

The  lemma  ensures  that  if  two  protocols  compose  safely,  then  any  of  the  next  configurations 
that  result  from  stepping  will  also  be  safe. 

Note  that  protocol  composition  does  not  enforce  that  the  shared  resources  are  not  lost.  Instead 
our  concern  is  on  safe  interference.  Indeed,  resources  that  are  never  used  will  never  be  able  to 
unsafely  interfere.  To  avoid  losing  resources,  we  must  forbid  the  use  of  (c-rs:None)  on  non- 
terminated  protocols  and  that  both  P  and  Q  cannot  have  both  simultaneously  terminated  if  there 
are  non-none  resources  left.  Once  that  restriction  is  considered,  our  splitting  induces  a  monoid 
in  the  sense  that  for  any  P  and  Q  for  which  T  b  R  ^  P  ||  Q  is  defined  there  is  a  single  such  R 
(defined  up  to  subtyping  and  equivalent  protocol/state  interference  specification).  Since  for  any 
two  protocols  there  may  not  always  exist  an  R  that  can  be  split  into  P  and  Q ,  this  is  a  partial 
monoid. 

Lemma  6.  Protocol  composition  obeys  the  following  properties: 

1.  ( identity )  Y  b  R  ^  R  ||  none. 

2.  (commutativity)  IfT  h  R  ^  P0  ||  P{  then  T  h  R  ^  P{  ||  P0. 

3.  (associativity)  If  we  have  T  b  R  ^  P0  ||  P  and  Y  b  P  ^  Pi  ||  P2  then  exists  Q  such  that 
r  b  R  ^  Q  II  Pi  and  Y\-Q^Pq\\P\. 

(i.e.  IfTvR^  P0  ||  (Pi  ||  P2)  then  Y  b  R  =*  (P0  ||  PO  ||  P2  ) 
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Protocol  composition  is  defined  as  a  “split”,  left-to-right  (^>).  Simply  reading  the  rules  as  right- 
to-left  (<^)  to  compute  a  “merge”  is  not  safe.  For  instance,  it  would  enable  merging  to  arbitrary 
choices  with  (c-rs:StateIntersection).  Intuitively,  merging  needs  to  intertwine  the  uses  of  both 
protocols.  However,  since  we  do  not  track  copies  (as  we  target  sharing  when  that  tracking  is  not 
possible),  merging  cannot  “collapse”  a  protocol  into  a  non-protocol  type.  In  this  case  “merging” 
is  equivalent  to  simply  having  the  two  non-merged  protocols  available  in  A  or  bundled  using  the  * 
type. 

The  composition  algorithm  is  shown  in  the  appendix  and  is  a  straightforward  implementation 
of  the  axiomatic  definitions  shown  above.  The  algorithm  uses  a  set  of  visited  configurations  to 
remember  past  configurations  and  ensure  that  once  all  different  protocol  configurations  are  ex¬ 
hausted  (up  to  renaming  and  weakening  of  T),  the  algorithm  can  terminate.  We  now  state  our 
technical  lemmas  on  the  composition  algorithm  but  leave  the  proofs  to  the  appendix. 

Lemma  7.  Given  well-formed  types  and  environment,  we  have  that: 

1.  (soundness)  if  c(  T,  R,  P,  Q)  then  T  l-  R  P  ||  Q. 

2.  ( completeness )  if  Y  h  R  ^  P  ||  Q  then  c(T,  R,  P,  Q). 

3.  (decidability)  c(T,  R,  P,  Q )  terminates. 

4.2  Correctness  Properties 

The  main  safety  theorems,  progress  and  preservation,  that  are  defined  over  valid  program  configu¬ 
rations  such  that: 

T  |  A,  h  ej  :  ![]  h  •  i  e  {0, ...,  n]  n  >  0 

-  (wf:Program) 

r  |  Ao,  ...,  A„  h  Co  ■  ...  ■  en 

Stating  that  a  thread  pool  (e0  ■  ...  •  en)  is  well  formed  if  each  thread  can  be  assigned  a  “piece”  of 
the  linear  typing  environment  (containing  resources),  and  if  each  individual  expression  has  type  ![] 
without  leaving  any  residual  resources  (•)•  Note  that  the  conditions  on  each  thread  (ef)  are  identical 
to  those  imposed  by  (t:Fork).  For  clarity,  both  safety  theorems  are  supported  by  auxiliary  theorems 
over  a  single  expression,  besides  the  main  theorem  over  the  complete  thread  pool. 

We  now  state  progress  over  programs: 

Theorem  1.  IfY  |  A  b  T()  and  live(T(j)  and  if  exists  H()  such  that  Y  A  h  H0  then  H0  ;  T0  i— >  H\  ;  7). 

live(T)  means  that  the  thread  pool  T  contains  at  least  one  “live”  thread  such  that  the  thread 
is  neither  a  value  nor  is  waiting  for  a  lock  to  be  released  (which  includes  deadlocks).  Y  |  A  l-  PI 
ensures  that  the  He ap  is  well-defined  according  to  Y  and  A. 

We  define  Wait(/7,  e)  over  a  thread  e  and  heap  H  such  that  the  Evaluation  context  is  reduced 
to  evaluating  the  configuration:  H  ;  <5[lock  p,p']  •  T  where  p  ■=-»  v  £  H  which  contains  at 
least  one  location  (p )  that  is  currently  locked  or  was  deleted  and,  therefore,  the  thread  must  block 
waiting  (potentially  indefinitely)  for  that  lock  to  be  available  before  continuing.  “Early”  deletion  of 
shared  resources  results  in  a  pending  guarantee.  Since  well-formed  threads  cannot  leave  residual 
resources,  this  situation  is  ruled  out  for  correct  programs,  but  may  occur  on  the  theorem  below. 
Progress  over  expressions  is  defined  as  follows: 
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Theorem  2.  IfT  |  A()  l-  e0  :  A  H  A  |  then  we  have  that  either: 


•  e0  is  a  value,  or; 

•  if  exists  H0  and  A  such  that  T  |  A,  A0  b  H0  then  either: 

-  (steps)  //o  ;  eo  b-»  Hi  ;  e\  ■  T,  or; 

-  (waits)  Wait(H0,e0). 

Preservation  ensures  that  a  reduction  step  will  preserve  both  the  type  and  the  effects  of  the 
expression  that  is  being  reduced  (so  that  each  thread’s  type,  ![],  and  effect,  •,  remains  unchanged). 
As  above,  we  use  a  preservation  theorem  over  programs  that  makes  use  of  an  auxiliary  theorem  on 
preservation  over  expressions: 

Theorem  3.  If  we  have  r0  |  A0  b  H0  and  r0  |  A0  h  Tq  and  Hq  ;  Tq  i->  H\  ;  T\  then,  for  some  Ai 
andT[,  we  have:  T0, Ti  |  b  H{  andY0,Yi  |  Aj  b  7). 

So  that  a  well-formed  pool  of  threads  (Tq)  remains  well-formed  after  stepping  one  of  these 
threads  (resulting  in  TO.  Preservation  over  a  single  expression  must  still  account  for  the  resources 
(At)  that  may  be  consumed  by  a  newly  spawned  thread  ( T ): 

Theorem  4.  If  we  have  H0  ;  e0  H\\  e\T  andY0  \  A0,  Ar,  A2  b  Hq  andY0  \  A0,  AT  b  e0  :  A  h  A 
then,  for  some  Ai  and  Ti,  we  have:  r0,  Ti  |  Ai,  Ar,  A2  b  H\  and  r0,  Tj  |  Ai  b  e\  :  A  h  A  and 
TotTi  I  Ar  b  T. 

We  complement  our  main  results  with  the  following  “Error  Freedom”  corollary  to  show  that 
our  system  cannot  type  programs  that  allow  data  races  and  the  dereference  of  destroyed  memory 
cells,  i.e.  that  our  system  ensures  memory  safety  and  race  freedom. 

Corollary  1.  The  following  program  states  cannot  be  typed: 

1.  (Data  Race)  Simultaneous  read/modify  by  two  thread  over  the  same  location  (we  also  ensure 
read-exclusive  accesses): 


H-,S0[p  :=  v]  •  Bd'-p]  •  T  H-8q(p  :=  v]  •  8l[p  :=  v']  •  T 

2.  (Memory  Fault)  Accessing  a  non-existing/deleted  location: 

H-8[p:=v]-T  H;8[\p\-T  (where  p  £  H) 

3.  ( Ownership  Fault)  Attempt  to  delete  a  non-existing  location: 

H\8[de!ete  p]  ■  T  (where  p  i  FI) 

The  proof  is  straightforward  due  to  our  use  of  locks  to  ensure  mutual  exclusion  and  the  fact  that 
our  protocols  discipline  the  use  of  shared  state.  Thus,  these  errors  are  ruled  out  by  either  protocol 
composition  or  by  the  resource  tracking  of  the  core  linear  system. 
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receive (c)  = 
rec  R. 
lock  c; 
case  ! c  o£ 

// 1 .  waiting  states  (A..Z) 

A#n  -»  ...  //  analogous  to  below 
I  Z#n  ->  // restore  linear  content 
c  : =  Z#n ; 

unlock  c; 

R  //  retry 

//  2.  desired  (receive)  state 
|  ReadyToReceive#v  — > 

c  :=  Idle#{};  //’’received” 

unlock  c; 

v  //  value  received  from  ’’channel” 

end 

end 


send(c,v)  = 
rec  R. 
lock  c; 
case  ! c  of 

// 1 .  waiting  states  (A..Z) 

A#n  -»  ...  //  analogous  to  below 
I  Z#n  ->  // restore  linear  content 
c  : =  Z#n ; 

unlock  c; 

R  //  retry 

//  2.  desired  (idle)  state 
|  Idle#_  — * 

c  :=  ReadyToReceive#v;  //’’sent” 

unlock  c; 

{}  //  result  of  send  is  empty 

end 

end 


Figure  11:  Simple  encoding  of  send  and  receive  functions  via  a  shared  cell. 


5  Protocol  Expressiveness 

We  show  the  expressiveness  of  our  protocols  by  modeling  typeful  message-passing  concurrency, 
using  a  straightforward  encoding  of  message-passing  via  shared  memory  interference  (Fig.  13). 
The  encoding  itself  should  be  unsurprising  as  it  follows  well-known  ideas  from  the  literature,  so 
we  defer  less  important  details  to  the  appendix  to  focus  instead  on  the  most  interesting  aspect  of 
this  example:  how  our  protocol  framework  is  able  to  type  such  uses  and  ensure  their  safety. 

We  encode  a  more  primitive,  “low-level”  view  of  typeful  message-passing  concurrency  via  the 
causality  of  shared  memory  interference.  We  focus  on  the  non-distributed  setting  where  a  channel 
can  be  precisely  encoded  as  a  low-level  shared  cell.  Channel  communication  and  its  changing 
session  properties  are  emulated  indirectly  via  inspection  of  or  interference  over  the  contents  of  that 
shared  cell.  Thus,  our  functions  to  send/receive  a  value  simply  hides  the  underlying  Waiting  states 
that  may  be  needed  when  the  cell  is  not  available.  A  receiving  step  can  be  modeled  by  a  protocol 
of  the  form: 

Wait[A..Z]  ©  (  rw  c  ReadyToReceive#V  =>  rw  c  Idle#[]  ;  NextStep  ) 

where  Wait  is  a  sequence  of  retry  steps  that  leave  the  state  unmodified,  until  a  value  of  type  V 
is  “received”.  Sending  uses  a  similar  protocol  but  where  we  must  wait  for  an  Idle  cell  before 
“sending”. 

The  appendix  includes  the  complete  “Buyer-Seller- Shipper”  example  (the  canonical  and 
simple  example  used  in  session-based  concurrency  works)  while  in  here  we  only  take  a  look  at  the 
main  aspects  of  the  Buyer’s  interaction  with  the  channel  (Fig.  18). 
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let  c  =  connectSellerO  in 

c  :  buy \(prod)  ;  price?(p)  ;  details?(ii) 

send(c,  GET_USER_PRODUCT()  ); 
let  price  =  receive (c)  in 

let  details  =  receive(c)  in 
close(c) 

end 

end 


Figure  12:  Buyer  code. 


We  model  a  channel  using  a  capability  to  location  c.  For  brevity,  we  omit  “rw  c”  from  “rw  c  A” 
since  all  changes  occur  over  that  same  location.  The  Buyer’s  type  uses  standard  ^--calculus  [23] 
notations  where  !  sends  and  ?  receives  a  value.  In  our  protocols,  these  actions  are  mapped  to  the 
rely  type  (receive)  and  the  guarantee  type  (send). 

buy  \(p  rod)  ;  price?(p)  ;  details 1(d) 

idle®#[]  =>  buy #prod  pri ce#p  =>  idle2#[]  details#^  =>  [] 

Buyer  starts  by  sending  a  request  to  buy  some  product,  then  waits  for  the  price,  and  finally 
receives  the  details  of  that  product.  Under  that  interaction  protocol,  we  simply  map  sends  to  a 
guarantee  type  of  a  step,  and  receives  the  a  rely  type  of  a  step. 

Our  protocol  interactions  are  both  non- deterministic  and  may  contain  an  arbitrary  number  of 
simultaneous  participants.  To  ensure  that  the  desired  participant  (Buyer)  is  the  only  one  allowed 
to  received  (take)  the  price,  we  must  mark  the  contents  with  a  specific  tag  so  that  only  Buyer  has 
permission  to  change  that  state.  To  handle  the  non-deterministic  interleaving  of  protocols,  we  must 
introduce  explicit  “wait  states”  that  allow  a  participant  to  check  if  the  communication  has  reached 
the  desired  point  to  that  participant  or  if  it  should  continue  waiting.  We  abstract  these  steps  as  Wait 
as  they  simply  recur  on  that  same  step  of  the  protocol  (i.e.  “busy-wait”). 

idle®#[]  =>  buy #prod  ;  Wait  ©  (price#p  =>  idle2#[] )  ;  Wait  ©  (  details#d  =>  [] ) 

The  richness  of  our  shared  state  interactions  means  that  we  can  immediately  support  fairly  com¬ 
plex  session-based  mechanisms  (such  as  delegation,  asynchronous  communication,  “messages  to 
self”,  multiparty  interactions,  internal/external  choices,  etc.)  within  our  small  protocol  framework. 
However,  this  flexibility  comes  at  the  cost  of  requiring  a  more  complex  composition  mechanism. 
Protocol  composition  accounts  for  both  non-deterministic  protocol  interleaving  and  “multi-way” 
communication,  features  which  are  usually  absent  from  strictly  choreographed  session-based  con¬ 
currency  (favoring  instead  strong  liveness  properties  over  more  deterministic,  linear  compositions). 

Naturally,  more  complex  examples  are  possible.  In  here  our  focus  is  on  showing  the  core 
insights  that  enable  us  to  relate  the  two  techniques:  1)  mapping  receive/send  to  our  rely/guarantee 
types;  2)  adding  explicit  waiting  states  to  account  for  non-deterministic  protocol  interleaving;  and 
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3)  tag  the  content  of  a  cell  in  order  to  ensure  that  only  the  right  participant  will  be  able  to  mutate 
the  state  at  that  point  in  the  interaction.  (Recall  that  we  do  not  guarantee  deadlock  freedom,  nor 
termination.) 


6  Related  Work 

Our  work  relates  to  prior  work  on  rely- guarantee  protocols  [21].  We  show  that  these  protocols 
are  useful  to  reason  about  concurrency  and  significantly  improve  the  flexibility  of  protocol  com¬ 
position.  Namely,  we  allow  the  composition  of  abstract  protocols  (enabling  more  local  typing  as 
in  Section  3),  show  that  our  composition  is  decidable,  and  provide  a  novel  axiomatic  definition 
of  composition  that  is  straightforward  to  implement.  Since  thread-based  interference  is  rooted  in 
alias-related  interference,  the  technique  itself  is  mostly  indifferent  to  whether  sharing  occurs  in  the 
sequential  or  concurrent  setting.  Still,  we  address  all  technicalities  that  make  concurrency  possible 
(such  as  adding  support  to  arbitrarily  many  threads,  locking  locations,  well-formedness  changes  to 
the  rely/guarantee  types  to  ensure  matching  lock/unlock  of  locations,  etc).  Furthermore,  by  con¬ 
sidering  the  concurrent  setting  we  are  able  to  express  and  relate  rely-guarantee  protocols  to  typeful 
message-passing  concurrency. 

Our  work  is  also  related  to  recent  work  on  more  precise  tracking  of  interference.  Chalice  [20] 
uses  a  simplified  form  of  rely-guarantee  to  reason  about  shared  state  interference  by  constrain¬ 
ing  a  thread’s  changes  to  a  two-state  invariant,  relating  the  previous  and  current  states.  Mono¬ 
tonic  [10,  28]  uses  of  shared  state  (where  all  changes  converge  to  more  precise  states)  are  less 
dependent  on  aliasing  information,  which  simplifies  checking  at  the  expense  of  expressiveness. 
Dynamic  ownership  recovery  mechanisms  [37,  29]  choose  some  run-time  overhead  and  dynamic 
safety  guarantees  to  enable  more  flexible  ownership  recovery  than  purely  static  approaches.  Rely- 
guarantee  references  [14]  adapt  the  use  of  rely-guarantee  to  individual  reference  cells  with  support 
for  dependent  refinement  types  in  a  sequential  language.  Although  the  use  of  refinements  adds 
expressiveness  to  the  description  of  sharing,  they  do  not  support  ownership  recovery,  nor  address 
decidability,  and  typechecking  can  require  manual  assistance  in  Coq.  Access  permissions  [37,  4,  3] 
control  alias  interference  by  categorizing  read-write  uses  into  different  permission  kinds.  Our  de¬ 
sign  omits  the  read-write  distinction  to  focus  exclusively  on  structuring  alias  interference  using 
more  fundamental  protocol  primitives.  Interestingly,  although  we  only  model  write-exclusive  uses, 
our  types  can  enforce  effectively  read-exclusive  semantics  by  ensuring  that  any  private  change  in 
a  cell  will  be  reverted  to  its  original  public  value.  However,  this  simpler  form  of  read-only  cannot 
capture  their  multiple,  simultaneous  readers  semantics.  Still,  by  modeling  interference  in  a  more 
fundamental  way,  we  gain  additional  expressiveness  beyond  their  most  permissive  share  permis¬ 
sion  as  we  can  model  uses  beyond  invariant-based  sharing.  In  [7]  Crafa  and  Pavodani  introduce  a 
high-level  (actor-like)  model  for  sharing  (type)state  via  join  patterns.  We  target  a  more  low-level 
programming  paradigm  (which  builds  typestates  through  type  abstraction  rather  than  as  a  first- 
class  language  feature),  enabling  us  to  introduce  abstraction  at  the  level  of  protocols  and  support 
protocol  re-splitting  in  ways  that  are  not  expressible  in  their  work. 

Several  recent  works  use  partial  commutative  monoids  [9, 19,  8]  to  model  sharing  by  leveraging 
the  concept  of  fictional  separation  [9,  15].  Commutative  monoids  offer  the  underlying  general 
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principle  for  splitting  resources,  enabling  seemingly  unrelated  components  to  interact  via  aliasing 
under  a  layer  of  (fictional)  separation.  We  compare  more  closely  to  [19]  due  to  our  common  use 
of  L3  [1]  and  type-based  approach.  In  [19],  Krishnaswami  et  al.  define  a  generic  sharing  rule 
based  on  programmer- supplied  commutative  monoids  for  safe  sharing  of  state  in  a  single-threaded 
environment.  Their  work  does  not  approach  the  issue  of  decidability  of  resource  splitting,  and 
requires  wrapping  access  to  shared  state  in  an  module  abstraction  that  serves  as  an  intermediary 
to  access  shared  state.  Our  work  focuses  on  a  custom  commutative  monoid  that  enables  first- 
class  sharing  without  (necessarily)  needing  a  wrapping  module  abstraction.  Although  our  protocol 
splitting  is  a  specialized  monoid,  we  showed  that  this  mechanism  is  relatively  flexible,  decidable, 
and  give  an  algorithmic  implementation.  Other  technical  differences  between  our  works  abound 
such  as  their  use  of  affine  refinement  types  (enabling  more  fine-grained  types),  our  use  of  multi¬ 
threaded  semantics  and  allowing  inconsistent  states  (i.e.  locked  cells)  to  be  moved  around  as 
first-class,  etc. 

Protocol-based  mechanisms  for  safe  interference  are  also  used  by  other  approaches,  such  as 
in  program  logic-based  systems  (e.g.  [17,  35,  36,  24,  11]).  By  generally  targeting  manual  proofs 
(and  somewhat  more  involved  specifications)  these  works  generally  fit  into  a  different  design  space 
than  ours,  although  share  some  interesting  similarities.  While  we  make  concessions  on  expressive¬ 
ness  to  achieve  decidable  protocol  composition  and  re-splitting,  these  works  focus  instead  on  the 
expressiveness  of  their  concurrency  specification.  LRG  [11]  supports  lock- free  structures  but  re¬ 
quires  a  special  frame -rule  to  support  framing  over  rely-guarantee  conditions.  We  simply  integrate 
protocols  into  the  language  (as  linear  resources)  meaning  that  the  standard  frame-rule  suffices. 
Supporting  lock-free  concurrency  in  our  system  would  require  reinterpreting  a  =>  step  as  a  single¬ 
cell,  atomic,  conditional  operation;  with  the  shared  resource  (stored  in  the  cell)  being  immedi¬ 
ately  extracted/inserted  from/into  the  cell,  rather  than  just  accessible  after  locking.  CaReSL  [36] 
and  Iris  [17]  support  “islands”/regions  of  memory  that  are  shared  together  and  whose  imprecise 
state  must  be  considered  when  using.  Our  composition  rules  enforce  that  a  protocol  carries  all 
information  on  imprecise  states,  which  is  then  deconstructed  via  (t: Alternative- Left)  and  case 
analysis.  Our  protocols  can  group  shared  state  using  the  *  operator  to  define  shallow  “regions”, 
while  their  works  allow  for  far  more  rich  specifications  of  atomic  regions  of  any  depth.  Iris  [17] 
further  supports  a  form  of  re-splitting  via  a  “view  shifting”  mechanism,  to  repartition  (or  create) 
shared  regions.  FCSL  [24]  encodes  protocols  via  auxiliary/ghost  state.  Although  done  in  a  compo¬ 
sitional  way,  it  can  require  checking  for  safe  interference  (“stability”)  after  a  split  since  a  safe  split 
does  not  necessarily  imply  safe  interference  in  all  situations.  Our  protocol  composition  mechanism 
is  essentially  a  form  of  checking  for  safe  interference  early,  at  the  moment  a  protocol  is  split,  by 
checking  that  all  possible  future  uses  are  safe  resembling  a  form  of  “pre-computed”  stability  check. 

Protocol  composition  itself  can  also  be  seen  as  a  form  of  model  checking  (to  check  that  each 
state  has  a  successor)  that  uses  abstract  states  to  ensure  a  finite  state  space,  but  in  a  system  that 
is  more  intimately  integrated  with  the  language.  Our  protocols  are  first-class  resources  that  can 
be  specialized  by  clients,  even  abstracting  (leaving  out)  later  steps.  Thus,  our  protocols  guide  the 
programmer  on  how  to  reason  locally  about  (safe)  interference  by  mapping  its  uses  of  locks  to  a 
local  protocol  type  that  models  the  alias  perspective  on  the  shared  state.  While  our  work  focuses  on 
modeling  the  core  interference  phenomenon  within  a  small  calculus,  rather  than  precisely  typing 
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existing  programs,  we  still  showed  that  extensions  may  be  used  to  model  at  least  some  existing 
programs  within  our  model. 


7  Conclusions 

We  defined  a  flexible  and  decidable  procedure  that  ensures  the  safe  composition  of  interfering  ab¬ 
stract  protocols  that  share  access  to  mutable  state.  While  employing  a  relatively  small  protocol 
framework,  we  are  able  to  model  the  core  interference  principles  of  complex  shared  state  interac¬ 
tions  within  our  core  calculus.  Finally,  we  showed  the  expressiveness  of  our  protocol  framework 
by  discussing  how  it  can  capture  in  a  unified  way  both  shared  memory  interference  and  typeful 
message-passing  concurrency. 
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A  Ensuring  Regular  Type  Structure 

The  decidability  statement  comes  as  a  direct  consequence  of  ensuring  a  regular  type  structure. 
Although  applied  in  the  context  of  protocol  composition,  we  follow  ideas  from  prior  work  on 
ensuring  decidable  subtyping  over  bounded  quantification  [32,  6].  The  main  novelty  is  in  extending 
this  kind  of  reasoning  to  account  for  recursive  types  with  parameters,  in  order  to  ensure  a  regular 
type  structure  over  our  more  expressive  unfolding.  To  achieve  this,  we  apply  well-formedness 
conditions  to  our  recursive  types.  We  favor  simpler  (as  in  more  “natural”)  constraints  that  make  our 
decidability  argument  clearer,  rather  than  try  to  achieve  more  permissive  conditions  by  considering 
lots  of  special-cases.  We  leave  to  compelte  set  of  well-formedness  rules  to  Appendix  G.l. 

To  illustrate  an  irregular  unfold,  consider  the  following  recursive  type,  R: 

(rec  R(X).(  int  -o  R[X  -o  X]  ))[int]  (Ex.l) 

Unfolding  this  type,  and  its  resulting  sub-terms,  produces  the  following  sequence  of  types  (for 
clarity,  we  underline  the  “fixed”  part  of  the  recursive  type  as  it  is  unfolded): 

(rec  R(XU  int  -o  R[X  -o  X]  ))  [int] 
int  o  (rec  R(X).(  int  -o  A[X  -o  X] ))  [int  -o  int] 
int  -o  int  -o  (rec  R(X).(  int  -o  7?[X  -o  X] ))  [(int  -o  int)  -o  (int  -o  int)] 


We  see  that  the  type  that  results  from  unfolding  is  not  regular,  as  the  use  of  the  recursive  variable 
R  in  “rec  R(X).(  int  -o  /^[  A  -o  X] )”  produces  a  type  that  is  non-repeating.  Consequently,  if  such 
a  use  were  allowed,  it  would  make  it  impossible  for  an  algorithm  that  traverses  all  sub-terms  of 
a  type  to  terminate  since  the  type  above  does  not  present  a  finite,  regular  structure  due  to  its  ever 
growing  argument  that  is  applied  to  the  recursive  type  R. 

To  forbid  uses  such  as  the  one  above,  we  limit  the  kind  of  arguments  that  may  be  applied  to  a 
recursive  type  variable  (such  as  R  above)  via  well-formedness  rules  (for  the  full  set  of  rules,  see 
appendix).  We  restrict  the  arguments  that  can  be  applied  to  a  recursive  type  variable  to  be  limited 
to  location  variables  or  type  variables,  and  exclude  recursive  type  variables: 

( X  :  ko  — >  ...  — >  kn  — >  type)  £  T  (£/;  :  kj)  6  T  i  6  [0, ...,  n} 

T  h  X[U]  type 

The  rule  states  that  for  a  given  recursive  type  variable  X  (recursive  type  variables  have  a  “...  — > 
type”  kind),  its  arguments  ( U )  must  each  be  an  assumption  of  compatible  kind  ((£/,  :  kj)  e  T). 
Since  we  are  considering  each  individual  k,  of  X,  these  can  only  be  either  a  loc  or  a  type  (and  never 
of  the  form  “...  — » type”)  which  effectively  enforces  that  only  location  variables  or  (non-recursive) 
type  variables  can  be  used  in  this  context.  Thus,  applications  of  the  form  A[  A ]  are  forbidden  since 
R  is  a  recursive  type  variable,  and  R[X  -o  X]  is  also  forbidden  since  the  argument  is  of  a  function 
type  (not  a  type/location  variable). 

Note,  however,  that  the  argument  applied  to  the  recursive  type  is  not  restricted  to  just  type/lo¬ 
cation  variables  and  instead  is  only  required  to  be  of  the  desired  kind: 
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Mo  :  ko, un  :  kn,X  :  k0  ->  ...  ->  kn  ->  type  b  A  type 
T  h  f/,-  fc;  C  =  kind(M,)  i  e  {0, 

T  b  (rec  X(m).A)[(7]  type 

where:  kind(Z)  =  loc  and  kind(X)  =  type.  Thus,  using  int  as  argument  in  (rec  Z?(X).A)[int] 
is  legal.  However,  because  we  only  allow  each  parameter  of  a  recursive  type  to  be  either  of  kind 
type  or  kind  loc,  recursive  type  variables  cannot  appear  as  arguments  (in  U )  even  in  this  situation. 
To  preserve  the  well-formedness  condition  on  uses  of  X[U']  we  must  also  avoid  situations  where 
substitution  from  other  recs  may  replace  some  argument  in  U'  with  a  non-variable  type  before  X 
is  unfolded.  Therefore,  the  body  of  rec,  i.e.  A,  must  ignore  all  other  variables  that  are  outside  the 
top-level  rec,  so  that  substitution  of  any  element  in  U'  will  only  occur  as  the  rec  is  unfolded. 

However,  only  using  the  restrictions  above  is  still  not  sufficient  to  ensure  that  the  algorithms 
will  terminate,  since  the  resulting  set  of  sub-terms  may  still  be  irregular.  Consider  the  following 
type: 

(rec  V(Z).(VX  <:  (A  -o  Z).V[X]))[int]  (Ex.2) 

If  we  traverse  the  sub-terms  of  this  type,  we  see  that  the  typing  context  of  the  “V[X]”  sub-term  is 
irregular,  although  the  type  structure  of  V[...]  itself  remains  regular. 

To  illustrate  this,  we  are  going  to  look  into  multiple  unfolds  of  V  but  only  show  the  premise 
that  is  used  to  check  that  V[...]  is  well-formed.  To  highlight  the  renaming  on  each  unfold,  each 
new  use  of  X  is  indexed  with  ever  growing  integers.  Although  we  are  traversing  the  rec’s  sub¬ 
terms  (automatically  unfolding  V  to  continue  such  traversal),  we  omit  all  “:  type”  assertions  to 
focus  instead  on  the  typing  context  that  is  used  to  check  that ‘T  h  V[.„]  type”  (i.e.  that  V[...]  is 
well-formed): 

•  b  V[int] 

X0<:  A- o  int  b  V[X0] 

Xx  <:  A  -o  X0,  X()  <:  A  -o  int  b  V[XJ 
X2  <:  A  -o  Xu  Xx  <:  A  -o  X0,  X0  <:  A  -o  int  b  V[X2] 

Consequently,  for  a  recursive  type  to  be  well-formed  we  must  also  ensure  that  the  enclosing  context 
of  future  unfolds  is  regular  since  it  is  not  enough  to  only  look  at  the  type’s  structure  alone. 

We  restrict  the  type  of  the  bound  of  a  V  or  3  such  that  the  bound  must  be  well-formed  in  the 
empty  context  “•  I-  A  type”  in  any  “3X  <:  A.B ”  or  “VX  <:  A.B ”  types  via  the  following  wf. 
conditions: 

•  h  A0  type  Y,X  :  type,X  <:  A0  h  A{  type  •  b  A0  type  Y,X  :  type,X<:A0  b  Ai  type 
T  b  VAcAq-A]  type  T  b  3X <: A0A|  type 

These  conditions  naturally  ensure  that  the  typing  contexts  in  a  type  must  be  regular  since  the  typing 
context  is  essentially  fixed  and  cannot  change  on  each  unfold.  We  leave  as  future  work  relaxing 
this  condition,  but  for  our  discussion  here,  this  well-formedness  restriction  is  enough  to  type  our 
examples  and  provides  an  interesting  domain  for  checking  safe  protocol  composition. 
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Still,  our  constraints  enable  some  flexibility  such  as  the  case  of  the  following  type,  that  can  be 
considered  regular  by  considering  renaming  of  variables  and  weakening: 

(rec  M(Y).(Y  -o  \/X  <:  top.Af [X]))[int]  (Ex.3) 

As  above,  we  illustrate  the  case  via  successive  unfolds  but  only  show  the  typing  context  used 
to  check  that  T  h  type  (i.e.  that  M[.„]  is  well-formed): 

•  h  M[int] 

X0  <:  top  h  M[X0\ 

Xx  <:  top,X0  <:  top  h  M[Xx\ 

X2  <:  top,Xi  <:  top,X0  <:  top  h  M[X2] 


By  inversion  on  weakening  of  assumptions,  we  can  consider  the  last  context  to  only  really  require 
the  “A2  <:  top”  assumption  (since  the  other  variables  do  not  occur  in  M\X2\).  By  renaming  X{) 
and  X2  to  some  fresh  variable,  both  the  first  and  third  types  can  be  deduced  equivalent  (=). 


Z  <:  top  h  M[Z]  =  Z  <:  top  h  M[Z ] 

(X2  <:  top){Z/X2}  h  ( M[X2]){Z/X2 }  =  (Xp  <:  top ){Z/X0}  h  WM 

X2  <:  top,  Xx  <:  top,X0  <:  top  h  M[X2]  =  X0  <:  top  h  M[XQ] 

We  consider  equivalence  (=)  up  to  renaming  of  variables  and  weakening  of  assumptions  de¬ 
fined  as  follows  (for  any  two  well-formed  types,  so  that  any  premise  must  also  obey  type  well- 
formedness): 


r  h  a 

r0,ri  h  Ao 

To  i-  Ao 
To  i-  Ao 


T  l- A  (equality) 

r2,r3  I- Aj  if  Ti  h  Ao  =  r3  Ax  (weakening) 

ri  h  A)  if  r0{Z/A(  h  A0{Z/X}  =  TilZ/F}  h  Ai{Z/F}  and  Z  fresh  (renaming  type) 

r3  i-  A i  if  Foll/t'}  \-Ao{l/t'}  =  h  A\{l/t]  and /fresh  (renaming  loc) 


The  following  lemmas  (see  appendix  for  proofs)  state  that  there  is  a  bound  in  the  number  of 
members  of  the  set  of  types  that  an  algorithm  will  recur  on. 

Lemma  8  (Finite  Uses).  Given  a  well-formed  recursive  type  ( rec  X{Ti).A)\U\  the  number  of  possi¬ 
ble  uses  ofX  in  A  such  that  T  h  X[U ']  type  is  bounded. 

Lemma  9  (Finite  Unfolds).  Unfolding  a  well-formed  recursive  type  ( rec  X(u).A)\  U\  produces  a 
finite  set  of  variants  of  that  original  recursive  type  that  (at  most )  contains:  permutations  ofU,  or  a 
set  of  mixtures  ofU  with  some  type/location  variables  representing  a  class  of  equivalent (=)  types. 


Lemma  10  (Finite  Sub-Terms).  Given  a  well-formed  type  A,  such  that  T  h  A  type,  the  set  of 
sub-terms  of  A  is  finite  up  to  renaming  of  variables  and  weakening  ofT. 
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B  Extra  Examples 

We  now  show  some  additional  examples  that  illustrate  the  expressiveness  of  the  full  language, 
how  we  can  model  some  high-level  synchronization  mechanisms,  and  clarify  modularity  gains 
when  compared  to  prior  works. 

B.l  Stateful  Pair,  revisited 

We  revisit  the  pair  example  from  [22]  to  highlight  the  changes  to  that  base  language.  Note  that  this 
particular  example  does  not  need  sharing.  To  clarify  which  location  belongs  to  which  variable,  we 
prefix  a  location  variable’s  name  with  an  @.  So  that  if  x  is  a  reference  then  it  will  have  location 
with  name  ‘@jc’  and  so  on. 

1  let  newPair  :  []  -O  PairType  =  A  _ . 

2  let  left  =  new  {}  in 

3  let  right  =  new  {}  in 

4  { 

5  initL  :  (  int  ::  (rw  ©left  [])  )  -o  (  []  ::  (rw  ©left  int)  ) 

6  =  A  i . left  : =  i , 

7  initR  :  (  int  ::  (rw  ©right  [])  )  -o  (  []  ::  (rw  ©right  int)  ) 

8  =  A  i. right  :=  i, 

9  sum  :  (  []  ::  ((rw  ©right  int)  *  (rw  ©left  int))  )  (  int  ::  ((rw  ©right  int)  *  (rw  ©left  int))  ) 

10  -A  _.  !left+!  right, 

11  destroy  :  (  []  ::  ((rw  ©right  int)  *  (rw  ©left  int))  )  — o  [] 

12  =  A  _. delete  left;  delete  right 

13  } 

14  end 
is  end 
i6  end 

The  type  of  the  newPair  function  remains  unchanged  from  [22]: 

!(  []  ^>  3EL.3ER.3L.3R.(  ![  initL:  !( int  ::  EL  -o  []  ::  L  ), 

initR  :  !( int  ::  ER  -o  []  ::  R  ), 
sum:  !([]::  L*R  -o  int::L*R), 
destroy  :  !([]::  L  *  R  -o  [])]::  EL  *  ER ) ) 

Although  the  existential  abstraction  (i.e.  packing)  is  done  via  subtyping  rules  rather  than  language 
constructs  as  in  [22]. 

B.2  Launching  Arbitrarily  Many  Threads 

There  is  no  restriction  on  the  number  of  threads  that  can  be  forked.  For  instance,  a  recursive 
function  can  launch  as  many  threads  as  it  sees  fit  to  compute  some  result,  which  may  also  cause 
the  computation  to  diverge. 
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1 


Oix.Crec  R.fork  ( . . . ) ;R)) ({}) 


B.3  Local  Protocol  Type 

The  type  system  only  needs  to  know  that  two  protocol’s  locations  are  related  when  we  are  com¬ 
posing  those  two  protocols.  Afterwards,  they  can  proceed  to  be  used  independently  (i.e.  they  are 
fictionally  disjoint  [19,  15]). 

Thus,  we  can  have  a  function  that  uses  the  protocol  3A.(  X  =>  rw  /  int ;  P  ): 
i  Ax . (  lock  x ;  x  : =  1 ;  unlock  x  ) 

Be  typed  with  the  following  function  type: 

VP.Vl.(  ( (!ref  /)  ::  3X.(  X  =>  rw  /  int ;  P  ) )  -o  ( []  ::  P ) ) 
which  in  turn  can  have  the  left  protocol  of  the  following  split  be  applied  as  its  argument: 

T  b  rw  p  int  3X.(  X  =>  rw  p  int ;  none )  ||  rec  X.(  rw  p  int  =>  rw  p  int ;  X  ) 

Thus,  the  location  relation  only  needs  to  be  know  when  protocols  are  composed.  Later  they  can  be 
abstracted  because  we  know  that  the  protocols  were  checked  to  be  safe. 

B.4  Abstraction  and  Locking 

Since  our  types  express  sharing,  we  can  use  standard  techniques  to  abstract  the  components  of 
a  protocol  after  safe  composition  is  checked.  However,  our  system  does  not  enforce  deadlock- 
freedom  and  abstracting  components  of  a  protocol  may  make  it  harder  for  the  programmer  to  tell 
if  there  is  a  chance  for  deadlock.  When  compared  to  [21],  we  lose  the  possibility  to  focus/lock 
on  abstracted  states  since  our  locks  require  a  set  of  locations  to  lock  on.  Still,  we  enable  an 
abstraction  to  allow  clients  to  lock  its  internal  state  through  the  use  of  some  “module”  that  exposes 
that  operation.  For  instance  consider  the  following  code  block: 

1  let  x  =  new  0  in 

2  //  share  x  as  some  protocols 

3  { 

4  lockMe  =  A  _.lock  x, 

5  //  ... 

6  } 

Although  x  is  not  visible  outside  the  code  that  creates  that  cell,  clients  can  call  the  function  to 
indirectly  lock  the  underlying  abstracted  state.  Thus,  the  record  can  have  type: 

[ ...,  lockMe  :([]::  (A  =>  B;  C) )  -o  ( []  ::  (A  *  (B;  C)) ),  ...  ] 

The  client  sees  that  some,  abstracted  protocol  is  expected  by  lockMe.  This  protocol  must  have 
been  produced  by  some  of  the  other  functions  of  the  record,  since  the  client  cannot  see  is  represen¬ 
tation.  When  lockMe  returns,  the  client  receives  a  type  that  expresses  that  A  is  available  and  that  a 
guarantee  (B;  C)  is  expected  to  be  fulfilled.  However,  there  this  fulfillment  can  only  occur  via  the 
wrapper  record  as  clients  have  no  access  to  its  representation. 
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B.5  Pipe  Example,  revisited 

We  now  revisit  the  pipe  example  of  [21]  to  clarify  expressiveness  gains. 

In  this  example,  two  aliases  interact  through  shared  state  such  that  one  alias  waits  for  another 
alias  to  insert  an  element  into  the  shared  cell.  The  protocols  are  not  exactly  identical  to  those 
shown  in  [21]  due  to  changes  to  support  thread-based  concurrency.  Namely,  our  protocol  types 
need  to  ensure  that  a  lock-token  invariant  is  preserved,  which  changes  how  protocols  express  own¬ 
ership  recovery.  Similarly,  because  abstractions  are  now  typing  artifacts  (to  support  abstractions 
over  protocols,  since  protocols  are  not  values)  this  enables  the  inspection  of  shared  state  without 
destructive  read  as  the  linear  component  of  a  node  can  be  placed  “on  the  side”  while  leaving  the 
content  of  the  cell  pure. 

We  use  the  following  abbreviations  for  the  states  of  the  protocols: 

Node[p]  =  3  q.(  (rw  p  Node#![element  :  int,  next  :  reft/])  *  H[t/] ) 

Close[p]  =  rw  p  Close#![] 

Empty[p]  =  rw  p  Empty#![] 

And  finally,  we  define  the  protocols  for  the  head  and  tail  aliases: 

T[p]  =  Empty[p]  =>  ( Close[p]  ®  Node[p] )  ;  none 
H [p]  =  (  Node[p]  =>  Node[p]  ;  Node[p] )  ® 

( Close[p]  =>  Close[p]  ;  Close[p] )  ffi  (  Empty[p]  =>  Empty[p]  ;  H[p] ) 

Note  that  although  the  shared  cell  can  be  freely  used  in  the  Empty  case,  those  changes  are 
only  allowed  privately.  This  means  that  the  contents  of  that  cell  must  forcefully  be  returned  to  its 
original  state  when  the  shared  cell  is  unlocked.  We  could  also  use  3  abstraction  over  that  step. 
Possible  pipe  implementation: 

1  let  newPipe  =  A 

2  let  node  =  new  Empty#{}  in 

3  //  using  explicit  sharing  annotation  to  make  it  clear  how  state  is  split 

4  share  (rw  @node  Empty# [])  as  H[@node]  ||  T[@node]; 

5  let  h  =  new  node  in 

6  let  t  =  new  node  in 

7  { 

8  put  :  int  ::  3p.((rw  @t  (ref  p))  *  T[p])  -o  []  ::  3p.((rw  @t  (ref  p))  *  T[/>]) 

g  =  A  e . 

10  let  last  =  new  Empty#{}  in 

11  let  old  =  !t  in 

12  lock  old; 

13  share  (rw  ©last  Empty#[])  as  H[@last]  ||  T[@last] ; 

14  old  :=  Node#{  element  =  e  ,  next  =  last  }; 

15  unlock  old; 

16  t  :=  last; 

17  end 

is  end , 
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20  close  :  int  ::  3p.((rw  @t  (re£  p))  *  T[p])  -o  [] 

21  =  A  _  . 

22  let  last  =  !t  in 

23  delete  t ; 

24  lock  last; 

25  last  :=  Closed#{}; 

26  unlock  last 

27  end , 

28 

29  tryTake  :  []  ::  3p.((rw  @h  (ref  p))  *  H[p])  -o 

30  NoResult#([]  ::  3p.(( rw  @h  (ref  p))  *  H[p]))  +  Result#(int  ::  3p.((rw  @h  (ref  p ))  *  H[p]))  +  Depleted#!] 

31  =  A  _  . 

32  let  first  =  =  !h  in 

33  lock  first; 

34  case  !  first  of 

35  Empty#_  — > 

36  unlock  first; 

37  NoResult#}} 

38  |  Closed#_  — > 

39  unlock  first; 

40  delete  h; 

41  delete  first; 

42  Depleted#}} 

43  |  Node#n  — > 

44  unlock  first; 

45  h  :=  n.next; 

46  delete  first; 

47  Re  sult#n.  element 

48  end 

49  end 

50  } 

si  end 

52  end 

53  end 

54  in 

55  //  ... 

Since  existential  types  are  automatically  opened,  we  use  the  @  prefix  on  a  variable  to  denote  its 
location  variable  that  was  automatically  opened.  Therefore,  if  t  is  a  ref  a  then  @t  denotes  location 
a.  Also  note  that  the  function’s  type  is  used  to  guide  type  checking,  meaning  that  the  type  the 
programmer  assigns  to  the  function  will  help  guide  the  type  system  to  move  capabilities  around 
and  abstract  types  to  match  the  desired  target  type. 

We  now  show  how  protocol  composition  proceeds  to  check  that  the  following  split  of  location 
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p  shares  the  state  safely: 


r  h  Empty[p]  =*  T[p]  ||  H [p] 

Protocol  composition  yields  the  following  set  of  configurations: 


<  r  h 

Emptyfp] 

T  [p]  II 

H  [p] 

) 

<  r  h 

Close[p]  ®  Node[p] 

none  || 

H  [p] 

) 

<  r  h 

Close[p] 

none  || 

Close[p] 

) 

<  r  h 

Node^] 

none  || 

Node[p] 

) 

<  r  h 

none 

none  || 

none 

) 

B.6  Futures 

Our  encoding  of  a  future  follows  that  of  fork/ join  but  wrapped  in  an  “object”  interface  with 
get  and  isDone  methods.  A  thread  will  compute  some  result  that  is  then  assigned  to  a  shared 
cell  (i.e.  a  thunk,  a  function  that  takes  no  argument  and  computes  an  expression  that  was  to  be 
evaluated  lazily).  If  the  object  representing  the  future  invokes  get  then  the  calling  thread  will 
block  until  the  computing  thread  finishes  the  result,  while  isDone  enables  inspection  on  whether 
the  computation  has  finished.  To  enable  the  uses  of  isDone,  the  M  protocol  shown  in  the  paper  is 
extended  with  an  additional  choice  to  allow  non-destructive  inspections  on  the  Done  tag.  Because 
our  protocols  are  first-class,  we  can  have  thunks  that  capture  part  of  the  shared  state  on  its  body. 
Although  the  code  is  interference-free,  it  may  still  deadlock. 

E  =  rw  t  Empty#[] 

D  =  rw  t  Done#int 
D[A]  =  rwtDone#A 

Join  =  E=>D;none 

End  =  (  E  =>  E;  End )  ©  ( (D  =>  (rw  t  int);  (rw  t  int))  &  3 F.(  D[T]  =>  D|Y];  End  ) ) 

1  future  e  = 

2  let  f  =  A_.e  in 

3  let  s  =  new  Empty#{}  in 

4  share  s  as  Join  | |  End; 

5 

6  fork  //  computes  result 

7  (let  r  =  Done#(f  {})  in 

s  lock  s ; 

9  s  :=  r; 

10  unlock  s 

11  end) ; 

12 

n  //  methods: 

14  { 
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15 


get  =  /!_.(  rec  R. 

16  lock  s ; 

17  case  !  s  of 

is  Empty#x  — > 

is  s  :=  Empty#x; 

20  unlock  s ; 

21  R  //  retry 

22  |  Done#a  — > 

23  s  :=  {}; 

24  unlock  s ; 

25  delete  s ; 

26  a  //  result  of  computation 

27  end 

28  end) , 

29 

30  isDone  =  d_.( 

31  lock  s ; 

32  case  !  s  of 

33  Empty#x  — > 

34  s  :=  Empty#x; 

35  unlock  s ; 

36  NotDone#{} 

37  |  Done#a  — > 

38  s  :=  Done#a; 

39  unlock  s ; 

40  Done#{} 

41  end 

42  end) 

43  } 

44  end 

45  end 

Client  code: 

1  let  f  =  future  fact (BQ®)  in 

2  ... 

3  //  get  value  computed  by  future 

4  f.getO 

5  end 

B.7  Barrier 

A  barrier  enables  a  fixed  number  of  threads  to  wait  for  all  those  threads  to  reach  the  barrier.  Only 
after  all  threads  have  reached  the  barrier  will  any  thread  be  allowed  to  continue. 

To  implement  this  barrier,  we  need  two  phases:  one  to  signal  that  a  thread  has  reached  the 
barrier,  and  another  phase  to  make  sure  that  all  threads  have  seen  that  the  barrier  synchronization 
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was  completed  (so  that  the  barrier’s  state  can  be  safely  destroyed).  Our  core  language  does  not 
support  reasoning  about  integers,  being  limited  to  a  finite  number  of  tags  of  a  sum  type.  Because 
of  this,  the  implementation  in  the  core  language  will  enforce  a  strict  order  in  changing  the  state 
of  the  barrier — but  which  does  not  limit  the  barrier’s  use  since  this  ordering  is  not  observable  to 
clients. 

In  the  core  language.  To  create  a  barrier  for  N  threads,  we  will  essentially  have  two  kinds  of 
protocols:  those  that  join  the  barrier  at  a  particular  stage,  and  the  last  thread  that  will  recover 
uniqueness  of  the  barrier’s  state.  Note  that  the  await  function  will  both  wait  for  the  thread’s 
correct  position  in  the  scheme  to  be  reached  and,  once  it  is  reached,  to  change  the  barrier’s  tag 
appropriately  to  acknowledge  that  the  thread  saw  that  all  threads  had  reach  the  barrier. 

For  clarity  of  the  example,  we  will  show  how  this  protocol  can  be  constructed  when  N  =  3, 
where  the  state  starts  with  the  Thread®  tag.  For  brevity,  we  only  list  the  tags  contained  in  some 
cell  and  not  the  full  type  of  the  capability  to  that  location. 

Threadl  =  Thread®  =>  Threadl  ;  rec  X.(  Threadl  =>  Threadl;  X  © 

Thread2  =>  Thread2 ;  X  © 

Ack®  =>  Ackl  ;  none  ) 

Thread2  =  rec  X.(  Thread®  =>  Thread®;  X  © 

Threadl  =>  Thread2 ;  rec  F.(  Thread2  =>  Thread2;  Y  © 

Ack®  =>  Ack®  ;  Y  © 

Ackl  =>  Ack2  ;  none  )  ) 

ThreadB  =  rec  X .  (  Thread®  =>  Thread®;  X  © 

Threadl  =>  Threadl;  X  © 

Thread2  =>  Ack® ;  rec  Y . (  Ack®  =>  Ack® ;  Y  © 

Ackl  =>  Ackl;  Y  © 

//  all  done,  recovers  shared  state 
Ack2  =>  rw  t  []  ;  rw  t  []  )  ) 

Naturally,  the  underlying  pattern  used  to  create  these  protocols  could  be  generalized  to  facilitate 
the  creation  of  similar  protocols  for  an  arbitrary  number  of  threads.  However,  our  core  language 
is  limited  to  only  list  a  finite  number  of  constants  that  are  used  to  tag  the  different  values  of  a  sum 
type.  Ideally,  we  would  instead  use  integers  to  reason  more  abstractly  about  these  tags  so  that  we 
do  not  need  to  check  each  individual  protocol  but  could  instead  consider  a  more  abstract  protocol 
representation  that  scales  better  to  higher  number  of  threads. 

While  in  this  version  we  must  treat  each  tag  individually,  with  “abstract”  integers  we  can  log¬ 
ically  collapse  arbitrary  large  number  of  tags  into  a  single  case  as  will  be  exemplified  in  the  next 
paragraph. 

Client  code: 

1  let  await  =  barrier(3)  in 

2  fork  C  ■■■;  await Q;  ...  ); 
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3  fork  C  ■■■;  await O;  ...  ); 

4  ... 

5  await () ; 

6  ... 

7  end 


Integers  instead  of  tags  We  now  sketch  how  we  can  model  barriers  in  a  language  where  integers 
can  be  reasoned  with  abstractly,  for  instance  using  type  refinements.  In  this  case,  we  only  have  one 
kind  of  protocol  and  the  value  found  in  the  shared  cell  distinguishes  the  allowed  behavior  of  the 
thread.  Unlike  previously,  this  also  means  that  we  can  join  without  statically  assigning  threads  a 
particular  order  of  joining  (although  that  does  not  affect  how  the  barrier  can  be  used). 

We  assume  that  the  cell  to  be  shared  initially  has  type  “rw  p  0”  and  the  integer  value  will  be 
used  to  count  how  many  threads  have  reached  the  barrier  and  seen  the  barrier’s  been  reached  by  all 
involved  threads. 

Barrier(N)  =  //  signaling  phase 

3{.r  :  int}.(  rw  p  x  =>  rw  p  x+1  )  ; 

//  “waiting”  point 

rec  R.  ( 

//  retry  in  case  value  is  less  than  N 

3{.r  :  int  |x<N}.(rwpx=>rwpx  ;  R)  ® 

//  acknowledge,  in  case  greater  than  N  but  not  the  last 

3{.r  :  int  |  x>=  N  A  x  <  (2N  -  1)} .  (  rw  p  x  =»  rw  p  x+1  ;  none  )  ® 

//  recover  ownership,  in  case  it  is  the  last  thread  to  acknowledge 

3{x  :  int  |  x  ==  (2N  -  1)| .  (  rw  p  x  =>  rw  p  null  ;  rw  p  null  ) 

) 


B.8  Merge  Task 

While  in  the  fork/join  case  we  statically  know  which  thread  will  compute  the  value  and  which 
one  will  wait  for  that  value,  in  here  we  design  a  more  dynamic  interaction  where  both  threads  are 
computing  some  result  and  the  last  to  complete  its  task  will  merge  the  two  results  together.  We  can 
use  the  following  protocol  for  the  case  where  there  are  only  two  participants: 

( Zero  =>  One ;  none )  ®  (  One  =>  Two ;  Two  ) 

The  shared  cell  goes  over  the  state:  Zero,  when  no  result  is  ready,  One  when  one  of  the  results 
is  done,  and  Two  when  the  last  thread  completed  its  task.  Note  that  by  using  a  finite  number  of 
labels  to  model  these  states,  we  are  limited  on  how  many  times  this  cell  can  be  shared.  In  this  case, 
limited  to  only  two  aliases  as  the  protocol  above  can  only  be  split  twice.  However,  we  could  use 
iterative  re-splitting  to  continue  to  aliases  further  more  by  essentially  extending  the  termination 
step  that  recovers  ownership. 
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Using  Extensions  Next,  we  can  sketch  the  protocol  that  we  would  use  if  our  language  was  able 
to  reason  about  integers.  We  use  an  auxiliary  cell  to  work  as  the  reference  counter,  since  we  will 
be  sharing  the  state  without  bounds.  Likewise,  we  do  not  impose  any  formal  conditions  on  how 
the  result  of  each  thread  should  be  merged  together,  only  that  it  is  of  type  int. 

Merger  = 

3{n  :  int  |  n  >  0} . 

(  (rw  p  int)  *  (rw  c  n)  =>  (rw  p  int)  *  (rw  c  n-1)  ;  none  ) 

® 

3 {n  :  int  |  n  ==  0} . 

C  (rw  p  int)  *  (rw  c  0)  =>  (rw  p  int)  *  (rw  c  0)  ;  (rw  p  int)  *  (rw  c  0)  ) 

To  ensure  that  only  one  will  recover  the  shared  state,  we  see  that  the  cell  c  must  contain  a 
integer  value  with  the  number  of  aliases  to  that  state  (i.e.  if  10  aliases  share  the  state  then  c  should 
contain  9  for  the  last  one  to  match  the  0  value). 

B.9  Shared  Pair 

This  example  shows  the  case  where  neither  alias  sees  the  “full  picture”  of  the  contents  of  the  shared 
state.  The  example  is  meant  to  illustrate  the  expressiveness  of  our  system,  since  the  example  itself 
is  somewhat  artificial.  However,  it  shows  that  each  alias  can  have  a  different  perspective  on  the 
contents  of  the  shared  state  such  that  each  alias  abstracts  different  components  of  the  pair. 

Consider  the  following  cell: 

rw  p  [A,  B] 

Such  a  cell  contains  a  pair  type  with  the  first  component  of  type  A  and  the  second  component  of 
type  B.  The  idea  is  to  now  share  that  same  cell,  including  its  contents,  through  two  aliases.  Each 
alias  will  not  modify  the  other  alias’s  pair  component,  although  the  state  of  the  cell  and  of  the 
alias’  pair  component  may  be  changed.  Due  to  the  typing  constraints  enforced  by  a  rely-guarantee 
protocol,  each  individual  alias’  actions  are  guaranteed  to  preserve  the  data  of  the  other  alias. 

The  crucial  bit  of  this  example  is  how  composition  will  have  to  proceed.  Since  part  of  the 
pair’s  type  is  abstracted,  an  alias  will  never  see  the  complete  type  of  the  pair.  However,  since  the 
other  alias  will  be  allowed  to  change  its  component,  composition  will  ensure  that  this  interference 
is  accounted  for  although  it  is  abstracted.  We  write  iX  to  abbreviate  iX  <:  top  and  3X  for 
3X  <:  top: 

P[A][fi]  =  rw  p[A,B] 

L [A]  =  3X.(  P [A][X]  =>  VY.(  P[Y][X]  ;  L[T]  ) ) 

R[A]  =  3X.(  P[A][A]  =*  VL(  P [X][Y]  ;  R[F]  ) ) 

T  h  P mm  ^  L[I]  II  R[F] 

Note  that  the  existential  cannot  last  longer  than  the  interval  where  no  interference  from  the 
other  alias  may  “appear”  in  the  pair.  Thus,  the  recursion  variable  X  must  include  a  fresh  existential 
to  model  the  new  type  that  may  appear  in  the  cell.  After  splitting,  each  alias  will  only  precisely 
know  the  type  of  its  own  component.  For  the  remaining  component  of  the  pair,  the  protocol  will 
enforce  that  the  alias  must  preserve  the  data  stored  there — although  that  alias  has  no  precise  type 
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information  on  what  its  type  may  be.  Therefore,  this  will  allow  a  form  of  local  hiding  that  yet  is 
globally  consistent. 

Protocol  composition  results  in  the  following  set  of  configurations: 

{  O  <  T  h  P[A][fi]  =>  L[A]  ||  R[B]  >, 

©  <  T,  X  :  type  h  P[A][X]  ^  L[A]  ||  R[X]  >, 

©  <  T,  y  :  type  h  P [Y][B]  ^  L [Y]  ||  R [B]  >, 

O  <  T,X  :  type,  Y :  type  h  P [X][Y]  ^  L[X]  ||  R[F]  >} 
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C  Examples  using  Informal  Extensions 


C.l  Monotonic  Counter 

In  this  example,  we  make  use  of  an  informal  extension  to  allow  types  akin  to  refinement  types  [12] 
to  model  more  precise  states.  With  this  extension  we  allow  more  fine-grained  interactions  than 
what  was  shown  in  the  paper.  While  prior  work  already  showed  how  a  simple  two-states  counter 
could  be  modeled,  we  show  here  how  a  more  precise  and  flexible  typing  can  be  built  using  the 
protocol  type  constructs  we  discussed  above. 

The  example  encodes  a  monotonic  counter,  similar  to  what  is  done  in  [28,  14],  but  encoded  in 
a  rely-guarantee  protocol.  The  type  will  share  a  single  location,  q,  using  the  protocol  below: 

MCounter[/n]  =  3{j  ;  int  |  j  >  m}.{  rw  q  j  =>  V]i  :  int  |  i  >  /}.(  rw  q  i ;  MCounter[i]  ) ) 

where  MCounter[/n  ]  is  indexed  by  a  type  m  that  represents  the  lower  bound  of  the  counter.  The 
guarantee  of  the  step  ensures  that  the  change  to  that  counter  will  be  greater  or  equal  than  the  base 
of  the  counter.  Thus,  we  have  that  the  types  m,  j,  i  represent  integers. 

Since  the  protocol  is  not  depending  on  a  specific  value  in  the  state  (the  value  on  each  step  is 
existentially  quantified),  the  protocol  can  be  shared  arbitrarily.  However,  through  the  universal 
quantifier,  the  protocol  is  also  able  to  store  a  more  precise  lower  bound  on  the  value  contained 
in  q.  This  protocol  ensures  that  the  value  stored  in  q,  although  it  can  undergo  intermediate  uses, 
will  keep  increasing.  Effectively,  the  interference  allowed  on  that  cell  is  iteratively/monotonically 
being  narrowed  down  on  each  step  of  the  protocol.  The  protocol  itself  is  usable  without  restriction, 
meaning  that  it  never  terminates  and  can  be  freely  split  into  other  protocols  that  obey  the  same 
initial  behavior  over  that  shared  cell. 

Client  code  We  now  exemplify  some  client  code  that  uses  the  protocol  above.  Since  our  formal 
system  does  not  have  refinement  types,  their  use  in  this  code  is  somewhat  informal.  Still  the 
intention  is  to  show  how  a  more  precise  monotonic  counter  can  be  modeled  by  a  rely-guarantee 
protocol: 

1  T  =  x  :  ref  p  ,  p  :  loc 

2  A  =  3n. (  rw  p  n  =>  Vm  :  m  >  n.(  rw  pm;  ...  )  ) 

3  //  opens  existential  (note  language  construct  hidden) 

4  T  =  x  :  ref  p  ,  p  :  loc  ,  n  :  type 

5  A  =  rw  p  n  =>  Vm  :  m  >  n.(  rw  p  m  ;  ...  ) 

6  lock  x;  // locks  cell 

7  T  =  x  :  ref  p  ,  p  :  loc  ,  n  :  type 

s  A  =  rw  p  n  ,  Vm  :  m  >  n.(  rw  p  m  ;  ...  ) 

g  x  : =  x- 1 ; 

10  A  =  rw  p  (n  -  1)  ,  Vm  :  m  >  n.(  rw  p  m  ;  ...  ) 

11  //  would  be  type  error  to  unlock  at  this  point 

12  x  :=  x+40; 

n  A  =  rw  p  (n  +  39)  ,  Vm  :  m  >  n.(  rw  p  m  ;  ...  ) 

i4  //  by  subtyping  we  can  apply  ”(n+39)”  as  m: 
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is  A  =  rw  p  (n  +  39)  ,  rw  p  ( n  +  39)  ; 
i6  //  thus,  we  can  now  unlock 

n  unlock  x ; 

is  A  =  3o  >  (n  +  39). (  rw  p  o  =>  ...  ) 


Composition  We  now  discuss  the  protocol  composition  configurations: 

{  O  <  m  :  int  I-  rw  q  m  ^  MCounterf/n] 

©  (m  :  int ,  n  :  n>  m  h  rw  q  n  ^  MCounterfn] 

©  <  m  :  int ,  n  :  n  >  m  h  rw  q  n  ^  MCounterf/n] 

©  (  m  :  int ,  n  :  n  >  m  ,  o  :  o  >  n  I-  rw  q  o  ^  MCounter[n] 

©  (  m  :  int ,  n  :  n  >  m  ,  o  :  o  >  n  I-  rw  q  o  ^  MCounter[o] 


MCounter[m]  ) , 
MCounter[m]  ) , 
MCounter[/?]  ) , 
MCounter[o]  ) , 
MCounter[/?]  )  } 


To  close  the  set  of  configurations,  we  must  extend  our  definition  of  equi-variance  to  consider 
states  up  to  the  transitivity  of  >.  Thus,  continuing  to  step  either  protocol  will  just  generate  equiva¬ 
lent  configurations. 


{  ©  (  m  :  int  I- 

©  (m  :  int ,  n  :  n  >  m  h 

©  (m  :  int ,  n  :  n  >  m  I- 

©  (  m  :  int ,  n  :  n  >  m  ,  o  :  o  >  n  h 

©  (m  :  int ,  n  :  n  >  m  ,  o  :  o  >  n  \- 


MCounter[m] 

MCounter[n] 

MCounter[n] 

MCounter[o] 

MCounter[o] 


MCounter[m] 

MCounterfn] 

MCounter[m] 

MCounterfn] 

MCounterfn] 


MCounterf/n]  )  , 
MCounterf/n]  )  , 
MCounterfn]  )  , 
MCounterfo]  )  , 
MCounterfn]  )  } 


The  case  where  there  is  a  mismatch  on  the  lower  bound  of  the  protocol  to  be  split  and  the 
resulting  protocol  is  not  completely  trivial.  It  is  important  to  note  the  subtlety  on  enabling  a 
protocol  to  work  with  a  lower  bound  on  the  value  of  the  cell.  Indeed,  this  just  amounts  to  weakening 
the  rely  type  since  the  guarantee  type  is  dependent  on  an  abstracted  type  that,  consequently,  remains 
unchanged — we  just  have  a  less  precise  bound  on  that  value.  Therefore,  we  have  that: 


MCounterf/?]  <:  MCounterf/n]  n  >  m 


since  we  are  weakening  the  rely  type  but  leave  the  effective  guarantee  type  unchanged. 


Discussion  Prior  work  in  the  area  makes  a  distinction  in  the  uses  of  the  monotonic  counter  based 
on  whether  the  action  is  enforced  or  simply  available  to  clients  if  they  choose  to  use  it.  In  our 
system,  these  uses  can  be  modeled  by  the  function  type  depending  on  whether  the  linear  protocol 
resource  is  used  or  not. 

For  instance,  the  type: 

3q.3n.(  ( !ref  <7)  ::  MCounterfn]  )  3m. ( []  ::  MCounterf/n]  ) 

Simply  allows  the  counter  to  be  used  an  arbitrary  number  of  times,  i.e.  it  allows  the  action  of  the 
counter  but  does  not  enforce  it.  If  the  client  so  chooses  it  can  use  the  monotonic  counter  zero  or 
more  times. 
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On  the  other  hand,  if  we  use  the  type  that  unfolds  a  single  step  of  the  protocol: 

3q.3mNX.{  (!ref  q)  ::  3{j  :  int  |  j  >  m}.(  rw  q  j  =>  V{z  :  int  |  i  >  /}.(  rw  q  i ;  X  )  )  -o  ( []  ::  X  ) ) 

Our  system  can  enforce  that  a  single  action  of  the  monotonic  counter  is  used  by  the  function,  thus 
that  the  counter  is  really  incremented  once.  Alternatively,  X  could  instead  just  be  the  monotonic 
counter’s  type,  thus  encoding  that  the  counter  is  used  once  or  more  times.  (Note:  the  use  of 
abstractions  over  refined  types  would  need  an  improved  kind  system  but  we  simplify  this  by  using 
plain  X  :  type  here). 

Consequently,  we  are  able  to  have  a  more  precise  type  than  prior  works  and  model  different 
kinds  of  uses  within  the  same  protocol  framework. 
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C.2  Monotonically  Growing  List 

Encoding  Read-Only  A  read-only  capability  (ro  p  A)  implies  that  the  cell  will  only  be  read, 
never  written  to.  Interestingly,  since  we  are  employing  a  model  where  all  accesses  to  some  shared 
state  must  be  protected  by  a  lock  (granting  exclusive  access  to  that  location),  we  can  encode  a 
meaning  similar  to  (exclusive)  read-only  access  without  explicitly  requiring  a  read-only  capability. 
Essentially,  if  there  will  not  be  any  concurrent  accesses  to  the  shared  cell,  a  shared  read-only  usage 
can  be  modeled  as  the  following  step  in  a  protocol: 

3A.(  rwpX=>rwpX;  ... ) 

since  it  will  enforce  that  the  cell  has  to  remain  publicly  unchanged  (since  any  temporary  write  is 
not  observable),  although  that  may  only  occur  after  some  private  uses.  Thus,  the  use  “looks”  like 
read-only  to  any  other  alias  of  that  state. 

Naturally,  if  concurrent  read-only  accesses  were  possible  then  we  would  need  a  proper  ro  ca¬ 
pability  to  ensure  that  no  intermediate,  private  values  are  placed  in  that  shared  cell.  Otherwise,  we 
could  also  define  a  different  =>  stepping  that  forbade  private  uses  and  requires  a  direct  transition 
from  the  rely  to  the  guarantee  type. 


In  this  example  we  are  modeling  a  monotonically  increasing  singly  linked  list,  similar  to  what 
is  done  in  [14].  All  the  nodes  of  the  list  are  technically  immutable,  so  that  the  pointer  to  the  next 
node  of  the  list  cannot  be  changed.  However,  the  list  contains  a  head  pointer  which  can  prepend 
new  nodes  to  that  list.  Since  each  of  those  nodes  is  immutable,  each  node  could  also  be  shared 
without  bounds  which  would  effectively  model  an  immutable  spaghetti  stack  if  multiple  shared 
nodes  could  point  to  one  same  (immutable)  next  cell. 

The  interesting  aspect  of  modeling  this  example  is  how  we  can  constrain  the  actions  of  the  head 
pointer  of  the  list.  To  illustrate  this  point,  we  use  a  list  that  already  contains  one  element  which 
simplifies  our  protocol  representation.  With  this  protocol,  we  can  enforce  a  more  specific  change 
to  the  shared  state:  the  head  pointer  is  required  to  add  one  (and  only  one)  new  node  that  points  to 
the  exact  same  fist  node  that  was  previously  in  that  shared  state,  if  the  shared  state  is  used  at  all. 
The  fist  protocol  wifi  ensure  that,  regardless  of  how  many  aliases  to  that  fist  exist,  if  any  alias  uses 
the  fist  then  it  must  forcefully  prepend  just  a  single  node  to  the  fist  as  its  sole  action. 


N[p]  =  Node#[  element  :  int ,  next  :  ref  p  ] 

Nil[p]  =  ro  p  Nil#[] 

Node[p]  =  3g.(  (  ro  p  N[g]  )  *  (  Node[g]  ©  Nil[g]  ) ) 


RootNode[g] 
L  [p\ 


(  rw  p  N[^] )  *  (  Node[g]  ©  Nil[g] ) 

3^.(  (  rw  p  N[<^]  )  *  (  Node[g]  ©  Nil[g]  )  => 

W.(  (  rw  p  N[t]  )  *  (  ro  t  N[g]  )  *  (  Node[g]  ©  Nil[g] ) ) );  L [p] 


The  important  aspect  is  the  constraint  on  the  location  that  the  new  guaranteed  cell  must  point 
to.  This  means  that  we  ensure  the  new  cell  that  was  added  correctly  points  to  the  previous  cell  of 
the  fist,  as  we  had  at  the  moment  of  focus.  The  protocol  explicitly  requires  a  prepend  to  occur.  We 


51 


could  also  include  (through  the  use  of  &)  additional  uses  that  could,  for  instance,  enable  the  client 
to  chose  whether  there  should  or  not  be  changes  to  the  list,  so  that  iterating  would  be  possible. 
Since  our  focus  is  on  only  showing  the  prepend  function,  we  omit  that  extra  case. 

We  now  show  the  implementation  of  the  prepend  function,  that  is  defined  as  a  closure  with 
access  to  the  list’s  head  pointer.  The  h(ead)  pointer  is  a  reference  to  a  location  (@h)  that  is  shared 
using  the  L[@h]  protocol  for  that  location. 

1  T  =  @h  :  loc  ,  h  :  ref  Oh 

2  A  =  L[Oh] 

3  prepend  =  A  x. 

4  T  =  x  :  int  ,  Oh  :  loc  ,  h  :  ref  Oh 

s  A  =  L[Oh] 

s  //  automatic  open  of  existential  of  L[@h] 

7  T  =  t :  loc  ,  x  :  int  ,  Oh  :  loc  ,  h  :  ref  Oh 

s  A  =  (  (  rw  Oh  N[f]  )  *  (  Node[f]  ©  Nil[f]  )  =>  ...  ) 

9  lock  h;  //  locks  location  of  head,  i.e.  ’@h’ 

10  A  =  rw  Oh  N[r]  ,  Nodeft]  ©  N i  1  [r]  ,  ... 

11  ...  ,  Vg.(  (  (  rw  Oh  N[<y]  )  *  (  ro  q  N[r]  )  *  (  Nodeft]  ©  Nil [r]  )  )  ;  L[0h]  ) 

12  let  n  =  new  Node#{  element  =  !h. element,  next  =  Ih.next  }  in 

13  A  =  n  :  3vv.(  rw  w  N[f]  ) 

14  //  automatic  open 

15  T  =  ...  ,  w  :  loc  ,  n  :  ref  w 

io  A  =  ...  ,  rw  w  N[f] 

I?  //  subtype  to  readonly,  this  cannot  be  reversed  back  to  writable! 
is  A  =  ...  ,  ro  w  N[f] 

19  A  =  ...  ,  rw  Oh  N[r]  ,  ro  w  N[f] 

20  h  :=  Node#{  element  =  x  ,  next  =  n  }; 

21  A  =  ...  ,  rw  Oh  N[w]  ,  ro  w  N[r] 

22  //  automatically  apply  location  ’w’  to  guarantee: 

23  A  =  ...,(((  rw  Oh  N[w]  )  *  (  ro  w  N[r]  )  *  (  Nodefr]  ©  Nil [r]  )  )  ;  L [p\  ) 

24  end ; 

25  //  it  is  ok  to  unlock  since  we  are  at  the  desired  guarantee 

26  unlock  h 

27  A  =  L[0h] 

Protocol  composition  becomes  easier  to  grasp  once  the  following  subtyping  relation  between 
states  is  observed: 

Vr.(  (  rw  p  N[r]  )  *  (  ro  t  N[<y] )  *  (  Node[g]  ©  Nil[g]  ) ) 

<: 

V/\(  (  rw  p  N[r]  )  *  3q.(  (  ro  t  N[g] )  *  (  Node[g]  ©  Nil[g] ) ) ) 

<: 

Vr.(  (  rw  p  N[r] )  *  Node[r] ) 

<: 

Vr.(  (  rw  p  N [t] )  *  (  Node[r]  ©  Nil[r] ) ) 
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Therefore,  we  have  that  the  rely  and  guaranteed  states  are  very  similar  except  for  referring 
different  location  variables.  Once  this  is  considered,  protocol  composition  is  straightforward. 

If  the  split  state  is  Node[p],  then  we  have  the  following  set  of  configurations: 

{  O  <  •  b  3<7.RootNode[<7]  ^  L[p]  ||  L[p]  )  , 

©  <  t  :  loc  b  RootNode[t]  L [p]  ||  L [p\  >  } 

Which  is  the  result  of  the  steps: 


( q  :  loc  b  (rw  p  N[g])  *  (...)  ^  (rw  p  N[g])  *  (...)  =>  Vt.(. . .)  ;  L)  i->  (q  :  loc  ,  t :  loc  b  Node[t]  ^  L) 
(•  b  3q.(  (rw  p  N[g])  *  (...))  ^  3q.{  (rw  p  N[g])  *  (...)  =»  Vt.(. . .) ) ;  L)  h-»  (t  :  loc  b  Node[f]  ^  L) 
0(-  b  3r/.RootNode[g]  ^  L)  (t  :  loc  b  Node[f]  ^  L)  © 


(t  :  loc  b  (rw  p  N[f])  *  (...)  ^  ( (rw  p  N[g])  *  (...)  =>  V/.(. . .)  ;  L  ){q/t})  h->  (/ :  loc  ,  t  :  loc  b  Node[/]  ^  L) 
(t  :  loc  b  (rw  p  N[r])  *  (...)  ^  3q.(  (rw  p  N[g])  *  (...)  =>  V/.(. . .) )  ;  L)  (/ :  loc  b  Node[/]  ^  L) 

©(?  :  loc  b  RootNode[t]  ^  L)  (I :  loc  b  Node[/]  ^  L)  © 
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D  Encoding  Typeful  Message-Passing  Concurrency 

We  now  discuss  how  our  protocols  can  be  used  to  encode  message-passing  style  of  concurrency, 
via  shared  memory  cells.  However,  our  encoding  only  works  in  a  non-distributed  setting  since  our 
core  language  does  not  account  for  actual  network  interactions — although  that  can  also  be  seen  as 
interacting  with  the  network  card’s  buffer.  Interestingly,  this  enables  values  to  be  shared  between 
threads  without  copying.  For  instance,  by  using  an  auxiliary  cell  to  store  values  and  just  move  that 
pointer  (and  capability)  between  the  threads  via  the  channel  (modeled  as  a  shared  cell). 

Due  to  the  underlying  protocol  types  and  its  shared  memory  underpinnings,  our  encoding 
can  send  “messages  to  self”  and  is  naturally  asynchronous.  This  flexibility  also  allows  for  non- 
deterministic  interactions,  when  different  alternatives  may  be  picked  depending  on  a  particular 
thread  scheduling.  Technically,  instead  of  sending  or  receiving  a  message,  the  interaction  occurs 
through  relying  and  guaranteeing  that  the  shared  cell  contains  values  of  a  certain  type.  The  novelty 
is  that  our  protocols  can  encode  both  shared-memory  and  message-passing  styles  of  interactions 
in  a  single,  unified  protocol  framework. 

We  now  discuss  the  high-level  concepts  of  our  encoding  of  message-passing: 

Channels  as  memory  locations.  To  create  a  new  channel  we  must  create  a  new  cell  that  will 
model  the  interaction  that  occurs  through  that  channel.  Similarly,  closing  a  channel  is  equiv¬ 
alent  of  deleting  that  memory  location,  which  effectively  negates  further  uses  of  the  cel- 
1/channel.  Since  the  communication  occurs  through  the  shared  location,  the  channel  name 
is  meaningless  as  long  as  the  specific  location  is  shared  by  the  two  endpoints,  even  if  using 
different  local  names  for  those  channels  /  location  variables. 

Sending  as  (little  more  than)  writing  to  shared  state.  Our  encoded  send  is  non-blocking  which 
means  that  the  thread  does  not  need  to  wait  for  the  other  party  to  receive  the  value.  This 
also  means  that  a  thread  can  send  a  message  to  itself,  if  the  programmer  so  wishes.  To  avoid 
overwriting  non-received  values,  the  exact  state  of  the  channel/cell  must  be  marked  with  a 
specific  tag.  This  is  akin  to  sending  or  waiting  for  an  acknowledge  that  the  value  has  been 
properly  received,  instead  of  potentially  flooding  the  receiver’s  buffer.  The  extra  complexity 
can  be  hidden  from  the  programmer  by  using  the  idioms  that  we  discuss  below. 

Receiving  as  (little  more  than)  reading  from  shared  state.  We  can  encode  receive  in  similar 
ways  to  sending,  so  that  we  may  need  to  mark  the  shared  state  with  a  specific  tag  so  that  the 
receiver  knows  that  the  cell  was  read  (and  thus  that  the  cell  is  available  to  write  to). 

Multiparty.  Our  channels  are  shared  cells  where  the  kind  of  communication  that  can  be  done 
through  those  shared  cells  is  only  constrained  by  the  protocol  type.  Thus,  whenever  the 
protocols  compose  safely,  that  interaction  is  ruled  valid.  As  we  saw  in  previous  examples, 
protocol  composition  allows  arbitrary  aliasing  and  therefore  multiparty  communication  (in¬ 
cluding  delegation)  is  naturally  supported  by  our  scheme. 

We  now  discuss  the  encoding  of  send/receive  shown  in  Figure  13.  The  underlying  principle  of 
these  idioms  is  to  hide  the  waiting  states  of  the  channel.  Client  code  will  then  look  identical  to  what 
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1  receive (c)  = 

2  rec  X.  //  recursion  point 

3  lock  c;  //  locks  location  of  ’c’ 

4  case  ! c  of 

5  // 1 .  waiting  states,  just  unlocks  and 

retries: 

6  A#n  ->  ...  //  analogous  to  case 

below 

7  |  B#n  -» 

s  c  i  —  B#n;  // restore  any  linear  type 

9  unlock  c ;  //  unlock  cell 

10  X  //  retry 

n  //  2.  desired  (receive)  state: 

12  |  ReadyToReceive#v  — > 

13  c  :=  idle#{};  //  marks  as 

received 

14  unlock  c ;  //  unlock  cell 

15  v  //  result  of  receiving  from  channel  ’ 

c’ 

io  end  //  end  case 

n  end  //  end  recursion 
is  //  at  this  point  c  has  type  P 


1  send(c,v)  = 

2  rec  X.  // recursion  point 

3  lock  c ; 

4  case  ! c  of 

5  // 1 .  waiting  states,  just  unlocks  and 

retries. 

6  A#n  ->  ...  //  analogous  to  case 

below 

7  |  B#n  -> 

s  c  B#n;  //  restore  any  linear  type 

s  unlock  c ;  //  unlock  cell 

10  X  //  retry 

11  //  2.  desired  (receive)  state: 

12  |  idle#_  — > 

13  c  :=  ReadyToReceive#v;  //signal 

sent 

14  unlock  c ;  //  unlock  cell 

is  {}  // result  of  send  is  unit 

16  end  //  end  case 

17  end  //  end  recursion 

is  //  at  this  point  c  has  type  P 


Figure  13:  Possible  encoding  of  send  and  receive  functions. 
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you  would  normally  see  on  traditional  message-passing  systems.  Therefore,  a  send/receive  will 
potentially  have  to  wait  if  the  cell  is  not  available  with  the  desired  tag  that  will  enable  “sending”  or 
if  it  has  no  new  value  to  “receive”.  Creating  a  new  channel  (new)  and  closing  a  channel  (close)  are 
straightforward  uses  of  memory  allocation  (followed  by  sharing  to  split  the  state  into  the  desired 
protocols  for  that  channel)  and  memory  deletion,  respectively.  Therefore,  we  will  only  look  into 
more  detail  on  the  encoding  of  receive  and  send. 

The  crucial  aspect  is  that  the  protocol  must  model  the  buffer’s  changing  state,  as  the  communi¬ 
cation  progresses,  enabling  the  encoding  to  seamlessly  wait  for  a  particular  phase  of  the  interaction. 

Consider  the  following  code: 

i  let  x  =  receive (c)  in  . . . 

To  receive  a  value  sent  to  channel  c,  we  need  to  wait  for  a  specific  state  to  be  stored  on  that 
cell.  This  waiting  is  based  on  the  specific  protocol  type  of  the  channel.  This  means  that  c  should 
have  a  type  of  the  kind: 

WaitSteps[A,  B, ...]  ©  (  rw  c  ReadyToReceive#V  =>  rw  c  idle#[]  ;  . . .  ) 

where  WaitSteps  are  just  (“busy-wait”)  cycles  in  the  protocol  that  retry  that  same  step  of  the 
protocol.  The  alternative  step  on  the  right  advances  the  protocol  when  the  right  value,  tagged  with 
ReadyToReceive,  is  found  in  c. 

Sending  is  analogous  since  it  must  also  wait  for  the  “channel”  to  be  free  (for  instance  by  being 
tagged  with  idle)  which  leads  to  the  recursion  that  spins  waiting  for  the  appropriate  tag  to  be 
present.  Similarly  to  send,  we  have: 

WaitSteps[A,  B, ...]  ©  (  rw  c  idle#[]  ^rwc  ReadyToReceive#V  ;  . . .  ) 

Note  that,  expanding  WaitSteps[A,  B]  above  yields  the  protocol: 
rec  X.(  ( A  =>  A; X  )  ©  (  B  =>  B\X)  ©  (  rw  c  idle#[]  =>  rw  c  ReadyToReceive#!7  ;  . . .  ) ) 

Open  Problems  Technically,  our  messaging  mechanism  is  a  queue  of  a  single  element.  The 
communication  can  occur  asynchronously  and  without  any  guarantee  of  global  progress,  making 
the  communication  vulnerable  to  live-locks  or  even  deadlocks  if  the  use  of  this  encoding  is  mixed 
with  locks. 

In  our  system,  to  ensure  safe  and  local  re-splits,  we  must  explicitly  list  all  the  waiting  phases 
of  the  communication.  While  in  traditional  message-passing  system  such  waiting  phase  is  hidden 
from  the  programmer,  our  receive  and  send  may  cause  the  current  thread  to  “busy-waiting”  when 
an  old  value  is  still  in  the  shared  cell.  (Although  overwrites  may  be  allowed  in  certain  situations, 
so  that  waiting  is  unnecessary  but  may  cause  the  interaction  to  be  somewhat  non-deterministic 
which  is  not  usual  for  message-passing.)  This  waiting  is  akin  to  blocking  the  thread  when  there  is 
no  actual,  higher-level,  mechanism  to  wait  on  some  event.  Technically  the  implementation  could 
employ  a  simple  optimization  that  registers  which  thread  should  wake  up  on  a  particular  state 
change  of  the  cell/channel,  but  we  do  not  approach  the  problem  of  finding  better  ways  to  schedule 
threads  to  reduce  excessive  spinning. 
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Figure  14:  Buyer-Seller-Shipper  message-passing  example. 

D.l  Buyer-Seller-Shipper  Example 

The  example  of  Figure  14  (adapted  from  [5])  shows  a  multiparty  communication  between  a  Buyer, 
a  Seller,  and  a  Shipper.  The  buyer  sends  a  request  to  buy  some  product  to  the  seller,  which  then 
replies  with  the  price  and  delegates  shipping  to  the  shipper.  The  shipper,  upon  receiving  the  request 
for  some  product,  then  replies  by  listing  the  shipping  details  back  to  the  buyer. 

We  follow  the  original  example  in  using  “session-delegation”  instead  of  opening  a  private  com¬ 
munication  channel  between  the  shipper  and  the  seller,  although  our  system  can  also  model  that. 
Similarly,  to  simplify  the  presentation,  we  do  not  abstract  a  channel’s  internal  states  even  though 
such  abstraction  would  produce  a  more  modular  protocol  specification. 

We  begin  by  modeling  the  communication  by  explicitly  labeling  the  messages  sent  through  the 
channel  using  the  ^--calculus  notation  of  “!”  for  sending  and  “?”  for  receiving,  and  extending  the 
notation  to  use  and  to  connect  or  delegate  the  communication. 

Buyer  :  Seller  <  buyl(prod) ;  price?(p) ;  details?(J) 

Seller  ^  buy l(prod) ;  price!(p) ;  Shipper  < product \(prod) 

Shipper  ^  product l(prod)  ;  detailsl(rf) 

The  types  above  define  a  Buyer  type  that  initializes  a  communication  (<)  with  the  Seller  server. 
From  the  perspective  of  the  Buyer,  the  buyer  sends  a  buy  message  (with  the  desired  product) 
and  waits  for  two  replies  in  that  channel:  one  with  the  price  and  another  with  the  details  of 
the  requested  product.  From  the  Seller  perspective,  on  each  new  request  (^),  the  seller  reads  the 
product  that  is  to  be  bought,  sends  back  the  price,  and  then  connects  to  Shipper  to  send  the  product 
information  while  delegating  to  Shipper  the  remainder  of  the  communication.  Finally,  Shipper, 
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channel 


Obuy! 

©price? 

©product? 

©details! 


(  idleO  ) 
buy 


(  idlel 
\  price 
•<(  idle2  )~ 
(product)*- 
idle3~~) 


(details 


©buy? 

©price! 

©product ! 

©  details? 


done 


Figure  15:  Buyer-Seller-Shipper  shared  channel’s  changing  session  state. 


on  each  new  request,  receives  the  product  and  sends  back  the  shipping  details  over  that  channel. 

To  model  this  interaction,  we  will  “merge”  all  communications  into  a  single  (coordinated) 
shared  cell.  Threads  will  wait  on  the  shared  cell  for  specific  tags  to  appear  in  the  shared  state. 
Similarly,  we  must  model  the  internal  states  of  the  “channel”  (i.e.  ready  to  receive,  ready  to  send, 
etc.)  explicitly.  Although  our  idiom  hides  these  temporary  states  from  the  programmer,  they  are 
needed  to  encode  the  interaction  in  our  rely-guarantee  protocols. 

We  begin  by  directly  translating  the  types  above  into  our  protocols,  ignoring  missing  “busy¬ 
waiting”  states  and  instead  focusing  only  on  the  useful  transitions  and  temporary  (idle)  states  (see 
Figure  15  for  a  schematic  of  how  the  different  channel’s  states  occur  within  the  communication 
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channel). 


Buyer  :  rw  c  idle©#[]  =>  rw  c  buy #prod  ; 
rw  c  price#/}  =>  rw  c  idle2#[]  ; 
rw  c  details#^  =>  rw  c  []  ; 
rw  c  [] 

Seller  :  rw  c  buy#pro<i  =>  rw  c  idlel#[]  ; 

rw  c  idlel#[]  =>  rw  c  price#/}  ; 
rw  c  idle2#[]  =>  rw  c  product#/}roJ  ; 

none 

Shipper  :  rw  c  product#/}roJ  =>  rw  c  idle3#[]  ; 

rw  c  idle3#/}ro<i  =>rwc  details#^  ; 

none 

where  the  initial  state  is  of  the  cell  is  “rw  c  idle®#[]”. 

We  now  add  the  necessary  waiting  states,  but  use  the  following  idiom  to  reduce  the  syntactic 
burden  and  only  list  the  tags  that  must  be  waited  on. 

wait  A  else  P  =  rec  X.(  (A0  =>  A0;X)  ®  ...  ®  (A„=>A„;X)  ffi  P) 

We  use  the  abbreviation  above  to  simplify  the  syntax  of  listing  each  “wait”  step,  although  our  A 
will  be  limited  to  listing  tags  and  not  the  full  type  for  simplicity.  Note  that  instead  of  manually 
inserting  wait... else,  we  could  instead  use/adapt  our  protocol  composition  mechanism  to  detect 
any  missing  state/steps  and  introduce  waiting  the  required  steps  to  ensure  safe  composition,  for 
this  particular  kind  of  message-passing  usage.  Still,  for  the  purposes  of  this  example  we  list  the 
missing  states  explicitly  but  gray  out  those  components  of  the  protocol  to  preserve  (some)  clarity: 

Buyer  :  rw  c  idle®#[]  =>  rw  c  buy#/}roJ  ; 

wait  buy,  idlel  else  rw  c  price#/}  =>  rw  c  idle2#[]  ; 
wait  idle2,  idle3,  product  else  rw  c  details#<r/  =>  rw  c  []  ; 
rw  c  [] 

Seller  :  wait  idle®  else  rw  c  buy#/} rod  ^rwc  idlel#[]  ; 
rw  c  idlel#[]  =>  rwc  price#/} ; 

wait  price  else  rw  c  idle2#[]  =>  rw  c  product #prod  ; 

none 

Shipper  :  wait  idle®,  idlel,  idle2, buy, price  else 
rw  c  product #prod  =>  rw  c  idle3#[]  ; 
rw  c  idle3  #prod  =>rwc  details#^  ; 

none 

In  our  scheme,  all  participants  must  be  aware  of  all  (public)  states  that  may  appear  on  the 
shared  state  to  enable  safe  re-splittings  later  on  (even  after  subtyping).  Therefore,  each  party 
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fork  //  Seller  server:  buy?  (prod)  ;  price !  (p)  ;  Shipper  <  product !  (prod) 
rec  L .  //  recursively  waits  for  new  connections 
let  c  =  listenSellerO  in 
fork  //  worker  thread  to  handle  this  connection 
//  the  product  that  is  to  be  bought 
(let  product  =  receive (c)  in 
//  do  something  with  product  to  find  price 
send(  c,  FETCH_PRICE (product)  ); 

//  splits  the  usage  of  the  protocol 
connectShipper (c) ; 
send(  c,  product  ) 
end) 
end; 

L 


Figure  16:  Seller  code. 


must  explicitly  know  the  state  it  is  to  wait  on  (and  not  change)  because  all  states  are  visible  and 
thread/alias  interleaving  can  be  non-deterministic. 

Implementation  Finally,  we  show  a  possible  implementation  of  this  interaction.  To  begin  the 
communication,  each  server  must  have  its  own  message  queue  to  receive  new  requests.  For  in¬ 
stance,  by  means  of  a  pipe.  It  is  this  pipe  that  stores  the  channel/cell  that  connects  the  two  endpoints 
to  establish  the  desired  communication. 

Assume  that  the  pipe  was  already  created  and  shared  by  assigning  to  each  endpoint  a  different 
role  in  the  use  of  the  pipe  (consumer  or  producer).  Therefore,  the  consumer  of  the  pipe  will  listen 
for  new  requests  to  be  pushed  into  the  pipe,  while  the  producer  will  insert  new  requests  onto  the 
pipe.  We  then  proceed  by  making  listenShipper  correspond  to  the  consumer  of  the  pipe  for 
the  Shipper  server  (that  will  do  successive  tryTakes),  while  connectShipper  is  the  correspond¬ 
ing  producer  that  will  push  new  values  into  the  pipe.  Analogously,  we  have  listenSeller  and 
connectSeller  for  similar  uses  but  for  the  Seller  server. 

Do  note  that  connectShipper  is  slightly  more  complex  than  just  the  use  of  a  pipe.  Indeed, 
to  create  a  new  channel,  connectShipper  will  also  have  to  create  the  new  cell  and  all  the  corre¬ 
sponding  protocols  of  the  interaction.  In  the  case  of  this  example,  this  corresponds  to  splitting  the 
usage  of  the  cell  in  three  protocols:  one  for  the  buyer,  one  for  the  seller  and  another  for  the  ship¬ 
per.  On  listenSeller  the  seller  will  receive  two  protocols  one  for  itself  and  another  for  shipper. 
Through  connectShipper  seller  will  send  shipper  the  part  of  the  protocol  that  was  delegated  to 
shipper. 

Figures  18,  16,  and  17  show  possible  implementations  of  the  three  communicating  processes 
using  the  receive  and  send  functions  discussed  above. 
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fork  // Shipper  server:  product? (prod)  ;  details !  (d) 

rec  L. 

let  c  =  listenShipperO  in 
//  get  product  info 
let  product  =  receive (c)  in 
//  send  shipping  details 

send(  c,  FETCH_SHIPPING_INFO (product)  ) 

end 

end; 

L 


Figure  17:  Shipper  code. 


// Buyer:  Seller  <3  buy!  (prod)  ;  price?(p)  ;  details?(d) 
let  c  =  connectSellerO  in 
sendCc,  GET_USER_PRODUCT ()  ); 
let  price  =  receive(c)  in 
let  details  =  receive(c)  in 
close(c) 
end 
end 
end 


Figure  18:  Buyer  code. 
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E  Complete  Technical  Development 

x  6  Variables  t  6  Tags  f  6  Fields  p  e  Location  Constants 


/  6 

Location  Variables 

X  e  Type  Variables 

P 

::=  p  |  /  w  ::  = 

l\X  U  ::=  p\A 

v  ::  = 

P 

(address) 

1 

X 

(variable) 

1 

Ax.e 

(function) 

1 

{f  =  W 

(record) 

1 

t#v 

(tagged  value) 

V 

(value) 

1 

v.f 

(field  selection) 

1 

V  V 

(application) 

1 

let  a  =  e  in  e  end 

(let) 

1 

new  v 

(cell  creation) 

1 

delete  v 

(cell  deletion) 

1 

!v 

(dereference) 

1 

v  :=  v 

(assign) 

1 

case  v  of  t#x  — >  e 

end  (case) 

1 

lock  v 

(lock  locations) 

1 

unlock  v 

(unlock  locations) 

1 

fork  e 

(spawn  thread) 

6  ::  = 

□  |  let  a  =  S  in  e 

(evaluation  contexts) 

Figure  19:  Values  (v),  expressions  (<?),  evaluation  contexts  (<5). 
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A 


!A 

A  -o  A 

[f Ta] 

Z/ 1 j#Ai 

V/.A 

3/.A 

VX  <:  A.A 
3X<:A.A 

ref  p 

X[U] 

(rec  X(u).A)[U] 
A  ®  A 
A  &  A 
rw  p  A 

none 

A  =>  A 
A;  A 

top 

A  ::  A 
A  *  A 


(pure/persistent) 

(linear  function) 

(record) 

(tagged  sum) 

(universal  location  quantification) 
(existential  location  quantification) 
(bounded  universal  type  quantification) 
(bounded  existential  type  quantification) 
(reference  type) 

(type  variable) 

(recursive  type) 

(alternative) 

(intersection) 

(read-write  capability  to  p) 

(empty  resource) 

(rely) 

(guarantee) 

(top) 

(stacking) 

(separation) 


Pairs,  recursion,  and  other  constructs  are  definable  in  the  language  as  was  done  in  [22]. 

Figure  20:  Types  (A). 
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Dynamics,  (d:*) 


H0;  T0  i— >  H  |  ;  T\ 


p  fresh 

(d:New) - 

H  ;  £[new  v]  i->  H,p  >  v  ;  £[p] 


(d’Dfiftf)  - 

H,p  v  ;  fi[delete  p]  h-»  H  ;  £[v] 


(d:Dereference)  - - - - - 

H,p  v  ;  £[!p]  t-»  //,p  <-»  v  ;  £[v] 


(d:Assign)  - -n - ^ - 

H,p  v0  ;  £[p  :=  vi]  e->  H,p  vi  ;  £[v0] 


(d:Application)  - 

H  ;  S[(Ax.e)  v]  i-»  H  ;  S[e{v/jc}] 


(d:Selection)  - - 

H  ;  £[{f  =  v}.f,]  H  ;  £[v,] 


(d:Case)  -  - - 

//  ;  £[case  t;-#v,-  of  t#x  — >  <?  end]  i->  //  ;  £[<?,•{ v//x/|] 


(d:Let)  - 

//  ;  £[let  a;  =  v  in  <?  end]  e->  //  ;  £[c]v/a;}] 


(d:Lock) - — — — — - ^ - 

H,p  v  ;  £[lockp]  i->  //,p*  e-»  v  ;  £[{}] 


(d:Unlock)  - ^ ^ - 

H,p *  v  ;  £[unlockp]  h->  //,p  v  ;  £[{}] 


(d:Fork)  - 

//  ;  £[forke]  h-»  //  ;  £[{}]•  e 


Ho ;  £[e0]  i->  //i ;  £[<?i]  •  T i 
(d:Thread)  - 

//o ;  £[e0]  •  £)  >->  //i ;  £[«i]  •  Tx  ■  T0 


Notes:  p?  ranges  over  p  (not  locked)  and  p*  (locked)  with  lock  token  unchanged.  We  use  f;  to 
denote  access  to  some  position,  i,  in  the  set  of  labels  f  (and  similarly  for  other  sets,  such  as  v,  t, 
etc.). 

Figure  21:  Operational  semantics. 
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T  |  A0  h  e  :  A  H  Ai 

Typing  rules,  (t:*) 

(t:Pure) 

(t:Pure-Elim) 

(t:Ref) 

r  |  •  b  v  :  A  H  •  (t:  Unit) 

r,x:A0\A0\-e:A1  H  A] 

r,p  :  loc  |  •  b  p  :  ref  pH-  T  |  •  h  v  :  !A  H  •  T  \  ■  h  v  : ![]  H  •  T  |  A0,  x  :  !A0  h  e  :  Ai  H  Ai 

(t:Selection)  (t:Record) 

(t: Pure-Read)  (t:Linear-Read)  T  |  A0  h  v  :  [f  :  A]  H  Ai  T  |  A  b  v  :  A  H  • 

r,  *  :  A  |  •  b  x  :  !A  H  •  r  |  jc  :  A  b  a;  :  A  H  •  V  |  A0  b  v.f :  A,-  H  A,  r  |  A  b  {f  =  v}  :  [f  :  A]  H  • 

(tiDelete)  (t:New) 

r  |  A0  h  v  :  3/.((!ref /)  ::  (rw  /A))  hA,  T  |  A0  b  v  :  A  h  A! 

T  |  A0  h  delete  v  :  31. A  H  Aj  r  |  A0  b  new  v  :  3/.((!ref  /)  ::  (rw  /  A))  h  Ai 

(t:Assign)  (t:Subsumption) 

r  |  A(|  Vj  :  Aq  H  A|  r  h  A()  c  A^  r  |  A^  b  :  A0  H  A2 

r  |  Aj  h  v0  :  ref  p  H  A2,rw  p  A{  Th  A0  <:  A{  T  b  A2  <:  A3 

r  |  A()  h  Vo  !=  V]  :  A 1  H  A2,  rw  p  Aq  r  I  Aq  b  6  A\  H  A3 

(t:Case) 

(t:Tag)  r  |  Ao  I-  v  :  t,-#A,-  H  Ai 

T  |  A  h  v  :  A  H  •  r  |  A1?  xt  :  A,-  l-  e,-  :  A  H  A2  i  <  ./' 

T  |  A  1-  t#v  :  t#A  h  •  T  |  A0  h  case  v  of  ty#;ty  <?;-  end  :  A  h  A2 

(t:  Application) 

(tiFunction)  r  I  Ao  h  vo  :  Ao  -o  Ai  h  A] 

r  |  A,  x  :  Ao  h  e  \  A\  -\  •  r  |  Ai  b  Vi  :  Ao  H  A2 

r  |  A  h  /tx.e  :  A0  -o  Ai  H  •  T  |  A0  F  Vo  Vi  :  A\  H  A2 

(t:Dereference- Linear)  (t:Dereference-Pure) 

r  |  A()  h  v  :  ref  p  h  Aj  ,  rw  p  A  T  |  A0  b  v  :  ref  pnA^rwplA 

T  |  A0  b  !v  :  A  H  Ax,  rw  p  ![]  T  |  A0  1-  !v  :  !A  H  A1?  rw  p  !A 

(t:Intersection-Right)  (t:Alternative-Left) 

r  |  A0  h  e  :  A0  h  Ai,  Ai  r  |  Ao,  Ao  b  e  :  A2  H  Ai 

r  |  A0  l-  e  :  A0  H  A1;  A2  T  |  A0,  Ai  b  e  :  A2  H  Aj 

r  |  Ao  l-  :  Ao  h  Aj ,  Ai&A?  r  |  Ao,  Ao  ©  A\  e  \  A2  H  Aj 
Figure  22:  Typing  rules  (1/2). 
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(t:Let) 


(t:Fork)  r  |  Aq  l-  :  Ao  h  Ai 

T  |  A  l- e  : ![] -l  •  T  |  Aj,  x  :  A0  I-  e\  :  A\  H  A2 

T  |  A  h  fork  e  : ![]  h  •  T  |  A0  h  let  x  =  <?0  in  ex  end  :  Ax  h  A2 

(t:Frame)  (t:Cap-Elim)  (t:Cap-Stack) 

r  |  Ao  h  c  :  A  H  Aj  r  |  Ao,  x  :  Aq,  Ai  l-  ^  i  At  h  Aj  r  |  Ao  I-  c  :  Ao  H  Aj ,  Aj 

r  |  A0,  A2  i-  e  :  A  h  Aj,  A2  T  |  Ao,  a:  :  Ao  ::  A\  \-  e  :  A2  h  Ai  T  |  A0  i-  e  :  Ao  ::  A\  H  Ai 

(t:Cap-Unstack)  (t:Forall-Loc-Val)  (t:Forall-Type-Val) 

r  |  A0  h  c  ;  A0  !!  A]  h  Aj  r,  / ;  loc  |  Aq  h  v  Aq  h  •  r, X  ;  type,  A  <!  A^  |  Aq  h  v  !  Aq  h  • 

r  |  A()  h  !  Aq  H  Aj  ,  A[  r  |  Aq  h  V  !  V/.Aq  H  •  T  |  Aq  h  V  !  VA  <!  A]  .Aq  H  • 


(t:Lock-Rely)  (t:Unlock-Guarantee) 


r  |  •  h  v  :  ref  p  H  •  locs(A0)  =  p 
T  |  A,  A0  =>  Aj  h  lock  v  :  ![]  H  A,A0,Ai 

(t:LocOpenBind) 

r,  / ;  loc  |  A0,  x  A  i  r  c  !  A2  H  Aj 
r  |  A0,  x  :  3l.Ai  1-  e  :  A2  H  Aj 

(t:TypeOpenBind) 

r,A  :  type,  A  <:  A0  |  A0,jc  :  Ai  h  e  :  A2  H  Ai 
r  |  A0 ,  jc  :  3A  < :  Aq  .AjI-c;A2hAi 


r  |  •  h  v  :  ref  p  h  •  locs(A0)  =  p 
|  A,  A0,  A0;  Ai  h  unlock  v  : ![]  h  A,  Ai 

(t:LocOpenCap) 

r,  1  \  loc  1  Aq,A]  i-  c  \  A2  h  A[ 

r  |  Aq,  3/.Aj  h  c  ;  A?  H  Aj 

(t:  T  ypeOpenC  ap) 

r,  A  ;  type,  A  <;  Ao  |  Ao,A[  1-  e  \  A2  h  Aj 
r  |  Aq,  3 A  <i  Aq.A ]  h  6  \  A2  h  Aj 


Notes:  bounded  variables  of  a  construct  and  type/location  variables  of  quantifiers  must  be  fresh  in  the  rule’s  conclusion. 
We  use  the  notation  f,  to  denote  access  to  some  position,  i,  in  the  set  of  labels  f  (and  similarly  for  3). 

Figure  23:  Typing  rules  (2/2). 


r 


A 

k 


T,  x  :  A 

T,  p  :  loc 

r,  Ac  A 
r,  A:  k 

A,  x  :  A 
A,  A 

type  |  type  — »  k  \  loc 


(empty) 

(variable  binding) 
(location  assertion) 
(bound  assertion) 
(kind  assertion) 
(empty) 

(linear  binding) 
(linear  resource) 
k  (kinds) 


Figure  24:  Typing  environments. 
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r  h  Aq  c  A] 


Subtyping  on  types,  (st:*) 


(st:ToLinear)  (stiPure)  (st:Weakening) 

<st:S»mmetry)  r  h  A„  <:  A,  r  PA„<:A,  (yePureTop)  r0  h  A  <:  g 


l  h  A  <:  A  r  h  !A0  <:  A,  F  h  !A0  <:  !A,  i  ^  !A  <:  !LJ  r0, F{  h  A  <:  B 


(st:Function)  (st:Alternative)  (st:Intersection) 

r  I-  Ai  <:  A3  r  h  A2  <:  Aq  T  h  A0  <:  A2  T  h  A0  <:  A2 
r  h  Ao  -o  Ai  <:  A2  -o  A3  r  h  Ao  <:  A2  ©  Ai  T  1-  A0&A1  <:  A2 

(st:Sum)  (st:Discard)  _  _ 

(s'eTop)  r  p  A,  <:  B,  n  <m  r  p  [f  :  A]  <:  [f  :  S]  f  :A*0 

mncnop  r p  S' t* <  S' «  rp  [FTa.  1  -.a'i  c  rfTsi 


(stiTypeVar) 

X  <:  A0  6  r  r  h  A0  <i  Aj 


T  h  X  <:  A, 


r  h  [f  :  A  ,  f'  :  A']  <:  [f  :  5] 

(st:Record) 

T  h  [f  :  A]  <:  [f  :  5]  A'  <: 
r  h  [f  :  A  ,  £  :  A'\  <:  \f  :  B  ,  f '  :  B'] 


(st:  Stack)  (st:Star) 

r  h  Aq  Aj  (STiCap)  F  h  Aq  C  A2 

r  h  A2  C  A3  r  h  Aq  <:  Ai  r  h  Aj  C  A3 

T  h  A0  ::  A2  <:  Aj  ::  A3  F  h  rw  p  A0  <:  rw  p  A\  T  h  A0  *  A{  <:  A2  *  A3 


(st:Alternative-Cong)  (st:Intersection-Cong)  (st:Loc-Forall) 

r  1-  A0  <:  A\  r  1-  A2  <:  A3  F  h  A0  <:  Ai  F  h  A2  <:  A3  T,  l :  loc  h  A0  <:  Ai 


r  h  Aq  ®  A2  c  A]  ©  A3  r  i-  AQ&A2  c  A[&A3  r  i-  v/.Aq  c  v/.Ai 

(st:PackLoc)  (st:Loc-Exists)  (st:LocApp) 

r  h  Aq  c  Ai  r,/ :  loc  h  A0  <:  A!  r,  / :  loc  h  A0  <:  At 

r  h  Ao  <:  3/.A,{//p}  r  h  B/.A0  <:  3/.A!  r  h  V/.A0  <:  A^p//} 

(st:PackType)  (st:TypeApp) 

r  h  A2  <:  Ai  r  h  Aq  c  a;  r  h  A2  <:  Aj  r,  X  :  type,  X<:A,h  A0  <:  A'0 
F  h  A0  <:  3X<:A1.Aq{X/A2}  rh  VXcA^Aq  <:  A(',{A2/X} 

(st:Type-Exists)  (st:Type-Forall) 

r,X  :  type,X  <:  A3  h  A0  <:  Ai  T,X  :  type,X  <:  A3  h  A0  <:  Ai 

r  h  3X <: A3.A0  <:  3X <:  A3.A1  F  h  VX<:A3.A0  <:  VX<:A3.Ai 

Note:  recall  that  ©  and  &  are  commutative;  thus  we  only  have  one  subtyping  rule  for  (st: Alternative)  and 
(  st:  Intersection)  . 

Figure  25:  Sub  typing  on  types  (co-inductive). 


67 


Ao  <:  Ai 


Subtyping  on  deltas,  (sd:*) 


(sd:Var) 

r  h  Aq  <:  Aj  Aq  <:  A  | 


(sd:  Share) 

(sd:Symmetry)  r  h  A()  <;  Ai>Ao  r  h  A()  ^  A!  ||  A2 


r  h  A0 ,  x  :  Aq  < :  A j ,  x  :  A ^  r  h  A  <:  A 


r  l-  A0  <:  Ai,  A1;  A2 


(sd:Star-R) 

T  l-  A,Ao,Ai  <:  A,Ai,A? 
T  h  A,A0,A!  <:  A,  A!  *  A2 


(sd:Star-L) 

T  h  A,  A0  *  Ai  <:  A,  Ai  *  A2 
T  h  A,A0  *  Ai  <:  A,A1sA2 


(sd:Type) 

r  h  A0  <:  Ai  r  h  A0  <: 
r  l-  A0,A()  <:  A1?Ai 


(sd:None-R) 
r  h  A0  <:  Aj 

r  h  A0  <:  Al5  none 


(sd:None-L) 
r  h  Aq  <:  Ai 

r  h  A0,none  <:  Ai 


(sd:Alternative-L) 

T  l-  A o,A0  <:  A! 
r  h  Aq,  A  j  <:  Ai 

r  h  Aq,A()©Ai  <:  A[ 


(sd  :  Intersection-R) 

T  h  A0  <:  Aj,Ai 
r  l-  Aq  <:  A !,A2 

r  h  Aq  <:  A j,A[&A2 


Figure  26:  Subtyping  on  linear  typing  environments. 
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E.l  Protocol  Composition 


C  ::=  (  T  h  R  ^  P  ||  Q  )  (configuration) 

|  C  ■  C  (configuration  union) 

(wf:  Split)  (wf:Configuration) 

(rh^^Piiot  Cit 

e  or 


P,0  ::=  (rec X(u).P)[UP]  \  X[UP]  \  P®P  \  P&P  |  none  |  S  =*  P  \ 

S  ;  P  |  31.P  |  V/.P  |  3X  <:  A.P  |  VX  <:  A.P 

5  ::=  (recX(w).S)[f^]  |  X[U^]  \  S  ®S  \  S  &S  |  none  |  A  *  A  \  rw  p  A 
R  ::=  P  |  S 

Figure  27:  Grammar  restrictions  for  checking  composition:  Protocols,  States,  and  Pesources  (ei¬ 
ther  a  protocol  or  a  state). 
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Composition,  (c:*) 


(c:Step)  (c:AllStep) 

<  T  h  R  ^  Kl[P\  )  ^  Co  RL[o]  =  □  ||  Q  C0  •->  C2 

%AQ] )  >-»  Ci  ^[a]  =P\\n  C^C3 

(  r  i-  R  ^  P  ||  Q  )  Co  •  Ci  Co  •  Ci  C2  •  C3 

Composition  —  Reduction  Step,  (c-rs:*) 

(c-rs:None) 

<  r  h  R  ^  7?[none] )  i->  <  r  h  R  ^[none] ) 

(c-rs  :  StateAlternative) 

(  T  I-  Rq  ^  'A | P\  )  Co  (c-rs:ProtocolAlternative) 

<  r  h  7?!  ^  <R[P]  )  C,  <  r  h  7?  =$■  ft[P0]  )  ^  C 

<  r  h  R0  ®Ri  ^  K[P]  )  i->  Co  •  C,  <  r  h  P  =*  ft[P0  ©A]  >  •-»  C 

(c-rs:ProtocolIntersection) 

(c-rs:StateIntersection)  (  T  h  A  ^[A>]  )  h_ >  Co 

( r  h  r()  =»  t?[P]  >  i->  c  ( r  h  r  =»  k[pj  )  h->  Ci 

<  r  h  Ro&Ri  ^  R[P] )  ■-»  c  ( r  h  p  =*  ^[Po&Pi] )  h>  Co  •  Ci 

Composition  —  State  Stepping,  (c-ss:*) 

(c-ss:Step) 

( r  h  So  ^  R[s 0  =>  Si-P] )  >->  < r  h  5!  =>  R[P] ) 

(c-ss:Recovery) 

<  r  h  5  ^  7?[S] )  h->  <  r  h  none  ^  ^[none] ) 

Composition  —  Protocol  Stepping,  (c-ps:*) 

(c-ps:Step) 

<n-5o=>51;0^«[5o=>51;P])^<ri-0^  R[P]  ) 


Figure  28:  Basic  protocol  composition  stepping  rules. 
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(c-rs  :  Weakening)  (c-  ss  :  ForallLoc) 

(  r0  b  R  ^  <R[P]  >  h-»  C  <  r,  l :  loc  b  5  =>  <R[S  =>  P]  >  h-»  C 

<  r0,  r,  b  p  ^  p[P]  >  c  <  r  b  s  =>  K[s  =$  v/.p]  >  i-»  c 

(c-ss:OpenLoc)  (c-ss:ForallType) 

<  r  b  5  =>  P[P{p//}]  )  C  <  T,X  :  type, X  <:  A  b  5  =>  P[S  =>  P]  )  C 

<  r  h  s  =*  K[3i.P]  )h+c  < r  h  s  =>  K[s  =$  vx  <  a.p]  >  c 

(c-ss:OpenType) 

ThAjcAo  (T\-S  ^<R[P{A{IX}])^  C 
(  T  b  5  =>  P[3X  <:  A0.P]  )  i — ►  C 

(c-ps:ExistsType)  (c-ps:ExistsLoc) 

<  r,X  :  type,  X  <:  A  b  P  ^  P[g]  )  h-»  C  <  T,/ :  loc  b  P  ^  P[g]  )  h-»  C 

<  r  b  3X  <:  A.P  ^  K[3X  <:  A.Q]  )^C  (  Y  b  3/.P  ^  P[3/.£]  )  i-»  C 

(c-ps:ForallType) 

<  T,X  :  type, X  <:  A  b  5  =>  P  ^  P[5  =>  Q]  )  ■-»  C 

<  r  b  S  =>  VX  <:  A.P  =>  P[5  =*  VX  <:  A.Q]  )  h-»  C 

(c-ps:ForallLoc) 

<  T,  / :  loc  h  S  =>  P  =>  <R[S  =>  2]  )  i-»  C 

<  r  b  S  =>  V/.P  =>  P[5  =>  Ml.Q]  )  h-»  c 

(c-ps:LocApp) 

<  r  b  5  =>  P{p/l}  ^  P[5  =>  Q]  )  h-»  C 

<  r  h  5  =>  v/.p  =>  K[s  =>  e] )  i-»  c 

(c-ps:TypeApp) 

r  b  Ai  <:  A0  <TbS  P{Ax/X}  P[S  =>  0]  )  i-»  C 
<  T  b  5  =>  VX  <:  A0.P  ^  P[S  =>  Q]  )  h-»  C 

P{A/A)  =  “substitution,  in  P ,  of  A  for  A” 

Note:  bound  type/location  variables  of  a  type  must  be  fresh  that  rule’s  conclusion. 

Figure  29:  Protocol  composition  abstraction  extension. 
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(c-rs  :  Subsumption) 

r  h  i?!  <:  R0  (  r  h  R0  ^  <R[P0 ] )  C  r  h  P0  <:  Px 
<  r  h  R{  =$■  <R[Pi]  )  C 

(c-ss:Recovery) 

r  h  s  o  <  i  s  i 

(  r  b  S0  ^  R[S  i])n(rh  none  ^  ^[none] ) 

(c-ss:Step) 

r  h  S  o  < :  S  i 

<  r  b  So  =»  ns,  =>  s2;P] )  <  r  h  s2  ^  R[P]  > 

(c-ps:Step) 

r  h  So  C  s,  rhS3  <:  s2 
<  r  h  So  =>  s2;  Q  =*  ns,  =>  Sy,P]  )  <  Y  h  0  ^  7?[P]  ) 

Figure  30:  Protocol  composition  subtyping  extension. 
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F  Algorithms 

F.l  Protocol  Composition 


c(  T,  R.  P.  Q )  Composition  Algorithm,  (c) 

(1)  c(r,R,P,Q)  =  c£(r,R,P,Q,9) 

(2)  c(T,  R,  P,  Q,  v)  =  /*  (c:Step)  and  (c: AllStep)  */ 

VCT  h  R'  eS>  P'  ||  Q')  e  (stp(T,  R,  <R[P],  v)  U  stp( T,  R,  R[Q\,  v)).(  c(r',  R' ,  R\  Q',  v  U  <r  h  R  P  ||  Q) ) ) 

stp( T,  R,  P ;  v)  Step,  ( stp) 

(3)  stp(  (r',T),  R,  R[R],  v;)  -  /*  (c-rs:Weakening)  */ 

0  if  (r  I-  R  ^  R[P])  e  v;  /*  considering  equality  up  to  (eq:Rec)  */ 

(4)  stp( T,  (rec  A(f7).R)[t/],  R[R],  v)  =  stp(T,  Rjrec X(u).R/X}{U /T<],  R[R],  v)  /*  (eq:Rec)  */ 


(5)  stp(  T,  R ,  R[(rec  A(M).R)[i/]],  v)  =  stp(T,  R,  R[R{rec  A(M).R/A}{t//M}],  v) 

(6)  stp(  r,  R,  R[none],  v)  =  {r  h  R  ^  R[none]} 

(7)  stp(r,S0,??[So=>Si:n  v)  =  {rt5,  ^  R[R]} 

(8)  stp(  r,  (So  =>  5 1;  Q),  R[S0  =>  5 1;  R],  v )  ^  {r  h  Q  ^  R[R]) 

(9)  stp(  T,  R()  ®R\,  R[R],  v)  4  stp( T,  Ro,  R[R],  v)  U  stp( T,  R\,  R[R],  v) 

(10)  stp(T,  Ro&Ri,  R[R],  v)  =  stp(T,  Ro-  7?[R],  v) 

(11)  stp(  T,  R0&R\,  R[R],  t')  =  stp(T,  R),  R[R],  v) 

(12)  stp( T,  R,  R[Ro  ©  Ri],  v)  4  stp(T,  R,  R[R0],  v) 

(13)  stp(  T,  R,  R[R()©R,],  v)  4  stp(T,  R,  RfR^,  v) 

(14)  stp(  T,  R,  RtRo&Ri],  v)  =  stp(r,  R,  R[Ro],  v)  U  stp(T,  R,  R[Ri],  v) 

(15)  stp( r,  S,  R[S],  v )  4  {r  h  none  ^  R[none]) 

(16)  stp(  T,  R,  Rl3l.Pl  v)  =  stp(T,  R,  R[R{p//}],  v) 

(17)  stp(  T,  R,  R[3A  <:  A0.R],  v)  = 

stp(T,  R,  R[R{Ai/A}],  v)  if  sbt(T,  Ai,A0) 

(18)  stp( T,  S,  R[S  =>  V/.R],  v)  =  stp((r,/ :  loc),  S,  R[S  =>  R],  v) 


/*  (eq:Rec)  */ 
/*  (c-rs:None)  */ 
/*  (c-ss:Step)  */ 
/*  (c-ps:Step)  */ 
/*  (c-rs:StateAlternative)  */ 
/*  (c-rs:StateIntersection)  */ 

/*  (c-rs:ProtocolAlternative)  */ 

/*  (c-rs:Protocol!ntersection)  */ 
/*  (c-ss:Recovery)  */ 
/*  (c-ss:OpenLoc)  */ 
/*  (c-ss:OpenType)  */ 

/*  (c-ss:ForallLoc)  */ 


(19)  stp(  T,  S,  R[S  =>  VA  <:  A.P ],  v)  4  stp((r,  A  :  type,  A  <:  A),  5,  R[S  =>  P],  v)  /*  (c-ss:ForalType)  */ 


Figure  31:  Protocol  composition  algorithm  (1/2). 
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(20)  stp(r,  31. P,  P[3l.Q],  v)  =  stp((r,/ :  loc),  P,  <R[Q\,  v) 

(21)  stp(T,  3X  <:  A.P,  P[3X  <:  A.Q],  v )  = 

stp((r,X  :  type.X  <:  A),  P,  P[Q],  v) 

(22)  stp(T,  S  =>  HP,  'R[S  =>  il.Ql  v)  = 

stp(  (r,/ :  loc),  S  =>  p  P[S  =>  Q],  v ) 

(23)  stp(T,  S  =>  VX  <:  A.P  <R[S  =>  VX  <:  A.Q],  v )  = 

stp(  ( T,X  :  type,  X  <:  A),  S  =>  P,  P[S  =>  Q],  v) 


/*  (c-ps:ExistsLoc)  *, 
/*  (c-ps:ExistsType)  *, 

/*  (c-ps:ForallLoc)  *, 

/*  (c-ps:ForallType)  * 


(24)  stp(T,  S  =>  V/.P,  ^[5  =>  Q],  v )  =  stp(T,  5  =>  P{//p),  ft[S  =>  g],  v)/*  (c-ps:LocApp)  * 

(25)  stp( r,  S  ^  VX  <:  A0.P,  PIS  =>  Q],v)=  /*  (c-ps:TypeApp)  * 

stp(r,  S  =>  P{Ai/X},  P[S  =>  Q],  v)  if  sbt(r,  Aj,Ao) 


Subtyping  extension: 

(7)  stp(r,S0,K[Si=>S2;P],v)MrhS2^K[P]}  if  sbt(r,S0,Si) 

(8)  stp(r,  (So  =>  S2;Q),  *R[Si  =>  S3;P],  v)  =  {r  b  Q=>P[P]}  if  sbt(T,  S0,  SO  A  sbt(T,  S3,  S 
(15)  Stp(r,  So,  9?[S !],  v)  4  {El-  none  ^  7?[none])  if  sbt(r,  S0,  S, ) 

Note:  Recall  that  (c-rs:  Subsumption)  is  admissible. 

Figure  32:  Protocol  composition  algorithm  (2/2). 


/*  (c-ss:Step)  */ 
2)  /*  (c-ps:Step)  */ 
'*  (c-ss:Recovery)  */ 
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F.2  Subtyping 

Our  subtyping  algorithm  follows  the  approach  of  [32,  2]  so  that  sbt  includes  a  trail  to  track  cycles 
and  close  the  co-inductive  proof. 


sbt(  r,  A,  B  ) 


(i.e.:  sbt(T  h  Ac.B)) 


0) 

(2) 

(3) 

(4) 

(5) 

(6) 

(7) 

(8) 
(9) 

00) 

(11) 

(12) 

03) 

(14) 

05) 

06) 

(17) 

08) 

09) 

(20) 


sbt(  r.  A,  B)  =  sbt(  r.  A,  B,%) 

sbt(  T,  A,  A,  t )  =  true 

sbt(  T,  !A,  B,  t )  4  sbt(  T,  A,  B,  t) 

sbt(  T,  [A,  ![],  t  )  =  true 

sbt(  T,  !A,  IB,  t )  4  sbt(  T,  A,  B,  t) 

sbt(  T,  A,  top,  t )  =  true 

sbt(  F,X,B,t)  =  ({X  <:  A)  e  O  A  sbt(  F,  A,  B,t) 
sbt(  (T,  F),  A,  B,t)  =  sbt(  r.  A,  B,  t ) 

sbt(  T,  (A  -o  B),  (C  -o  D),  t )  =  sbt(  T,C,A,t)  A  sbt(  F,  B,D,t) 
sbt(  T,  (A  ::  B),  (C  ::  D),t)=  sbt(  F,A,C,t)  A  sbt(  F,  B,D,t) 
sbt(  T,  (rw  /  A),  (rw  l  B),  t )  =  sbt(  T,  A,  B,  t) 
sbt(  T,  (A  *  B),  ( C  *  D ),  t )  4 

(sbt(  r,  A,  C,  t )  A  sbt(  r,  B,  D,t))y  (sbt(  r,  A,  D,  t )  A  sbt(  F,  B,  C,  t )) 

sbt(  r,  3/.A,  31. B,  t )  =  sbt(  (r,  /  :  loc),  A,  B,  t ) 

sbt(  T,  V/.A,  Vl.B,  t )  =  sbt(  (r,  l :  loc),  A,  B,  t) 

sbt(  T,  3X  <:  A.B,  3X  <:  A.C,  t )  =  sbt(  (r,X  <:  A,X  :  type),  B.  C,  t) 

sbt(  T,  VX  <:  A.B ,  VX  <:  A.C,  t )  =  sbt(  (r,X  <:  A,X  :  type),  B,  C,  t ) 

sbt(  (F,  O,  A,  B,  t)  —  ((r  i-  A  <:  B)  e  t) 

sbt(  T,  (rec  X(u).A)[U],  (rec  Y(u').B)[U'],  t )  4 

sbt(  T,  A{rec  X(u).A/X}{U / u },  _B{rec  Y(u').B/Y}{U' /u’},  (t  U  (r  i-  (rec  X(M)-A)[t/] 

sbt(  T,  (rec  X(U).A)[U],  B,  t)  = 

sbt(  T,  A{rec  X(u).A/X}{U /u},  B,  (t  U  (r  h  (rec  X(u).A)[U ]  <:  B) ) 
sbt(  T,  A,  (rec  Y(u').B)\U'],  t )  = 

sbt(  T,  A,  Z?{rec  Y(u').B/Y}{U' /u'},  (t  U  (r  i -Ac  (rec  Y{u').B)[U'])) ) 


/*  (st:  Symmetry)  */ 
/*  (st:ToLinear)  */ 
/*  (st:PureTop)  */ 
/*  (st:Pure)  */ 
/*  (st:Top)  */ 
/*  (st:TypeVar)  */ 
/*  (st: Weakening)  */ 
/*  (st:Function)  */ 
/*  (st: Stack)  */ 
/*  (st:Cap)  */ 
/*  (st:Star)  */ 

/*  (st:Loc-Exists)  */ 

/*  (st:Loc-Forall)  */ 

/*  (st:Type-Exists)  */ 

/*  (st:Type-Forall)  */ 

/*  (eq:Rec)  */ 

/*  (eq:Rec)  */ 
<:  (rec  Y(i?).B)[U'])) ) 

/*  (eq:Rec)  */ 
/*  (eq:Rec)  */ 


Figure  33:  Subtyping  algorithm  (1/2). 
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(21)  sbt(  r.  A,  B  0  C,  t )  =  sbt(  Y,  A,  B,  t)V  sbt(  T,  A,  C,  t) 

(22)  sbt(  T,  A  ®  B,  C  ®  D,  t )  =  / 

(sbt(  T,A,C,t)A  sbt(  T,  B,  D,  t))W  (sbt(  T,  A,  C,  t )  A  sbt(  T,  B,  D ,  t )) 

(23)  sbt(  T,  A&B,  C,  t )  =  sbt(  F,  A,  C,  t)V  sbt(  Y,  B,  C,  t) 

(24)  sbt(  T,  A&B,  C&D,  f )  =  /: 

(sbt(  T,A,C,t)A  sbt(  T,  B,  D,  t ))  V  (sbt(  Y,  A,  C,  t)  A  sbt(  T,  B,  D ,  t )) 

(25)  sbt(  r,  2?  t i#Ah  YjT  t i#Bi,  t )  —  n  <  m  A  A"  sbt(  Y,  Ah  B„  t ) 

(26)  sbt(  T,  [f  :  A,  f'  :  A'],  [f  :  B],  t )  = 

[f  :  A]  4=  0  A  sbt(  T,  [£:  A],  [f  :  B],  f ) 

(27)  sbt(  T,  [f  :  A,  f'  :  A'],  [f  :  B,  f  :  B'],  t )  4 

sbt(  r,  A',  B',t)  A  sbt(  r,  [f  :  A],  [f  :  B],  t ) 

(28)  sbt(  A  A,  31. B,  t )  =  sbt(  Y,  A,  B{p/l},  t ) 

(29)  sbt(  A  V/.A,  B,  t )  =  sbt(  (Y,  l :  loc),  A{p/l],  B,  t ) 

(30)  sbt(  T,  A,  3X  <:  B.C,  t )  =  sbt(  Y,  A,  C{D/X},  t )  A  sbt(  Y,  D,  B,  t) 

(31)  sbt(  A  VX  <:  A.B,  C,t)±  sbt(  (r,X  <:  A,X  :  type),  B{D/X},  C,t)  A  sbt(  Y,  1 

Figure  34:  Subtyping  algorithm  (2/2). 


/*  (st:  Alternative)  */ 
'*  (st:Alternative-Cong)  */ 

/*  (st:Intersection)  */ 
*  (st:Intersection-Cong)  */ 

/*  (st:Sum)  */ 
/*  (st:Discard)  */ 

/*  (st: Record)  */ 

/*  (st:PackLoc)  */ 
/*  (st:LocApp)  */ 
/*  (st:PackType)  */ 
9,  A,  t )  /*  (st:TypeApp)  */ 
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G  Auxiliary  Definitions 

G.l  Well-Formed  Types  and  Environments 

Well-formed  conditions  are  not  explicitly  mentioned,  but  are  assumed  to  be  present  whenever  they 
are  relevant. 

Definition  1  (Well-Formedness).  We  have  the  following  cases  (defined  by  induction  on  the  struc¬ 
ture  of  the  type/environment): 


r  wf 


(Gamma) 


•  wf 


T  wf 

T,  p  :  loc  wf 


T  wf  T  h  A  type 
Y,X  :  type,X  <:  A  wf 


r  wf  r  h  A  type 

T,x:  A  wf 


r  h  a  wf 


(Delta) 


T  h  A  wf  r  h  A  type  T  b  A  wf  T  h  A  type 
T  h  •  wf  f  b  A,  x  :  A  wf  T  h  A,  A  wf 


r  h  P  loc 


(Location) 


r  h  A  type 


r,  p  :  loc  l-  p  loc 


(Type) 


T  h  A  type  T  b  A,  type  T  b  A0  type  Y  h  Aj  type 

r  b  none  type  Y  b  !A  type  r  b  [f  :  A]  type  T  b  A0  -o  Aj  type 

T  b  A0  type  T  b  Ai  type  Y  b  A0  type  Y  b  Ai  type 

T  b  A0  ::  Ai  type  Y  b  A0  *  A{  type 

T  b  A0  type  r  b  Ai  type  Y  b  A0  type  Y  b  Ai  type 

T  b  A0  ®  Ai  type  Y  b  A0&Ai  type 


r  b  p  loc 

r  b  A  type  T  b  p  loc  Y,  l :  loc  b  A  type  Y,  l :  loc  b  A  type 

T  b  rw  p  A  type  f  b  ref  p  type  Y  b  V/.A  type  Y  b  31. A  type 
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•  h  A0  type  r,  X  :  type,  X  <:  A0  h  Ai  type 

T  h  VX<:A0.Ai  type 

•  h  A0  type  T,  X  :  type,  X<:  A0  h  A\  type 

T  h  3X<:A0.Ai  type 


T  h  Ai  type  T  h  A0  type  ThAi  type 

r  h  X,  t i#Ai  type  r  h  A0;  Aj  type 

T  h  A0  type  T  h  Ai  type  locs(A0)  =  locs(Ai)  ±  0 
r  i-  A0  =>  A,  type 

uQ  :  k(),  ...,un  :  kn,X  :  kQ  ...  kn  type  h  A  type 
T  h  Ui  ki  kj  =  kind(w,)  i  e  {0,  ...,n} 

T  h  (rec  X(Ti).A)\U\  type 

(X  :  k0  ->  ...  ->  kn  -»  type)  6  T  ( £/,- :  £,-)  e  T  i  e  {0, ..., rc} 

T  h  X\U\  type 

where: 

kind(/)  =  loc 
kind(X)  =  type 


G.2  Set  of  Locations  of  a  Type 

Definition  2  (Locations  of  a  Type). 

locs(rw  p  A) 

= 

{ P } 

locs(A0  *  AO 

= 

locs(A0)  U  locsCAO 

locsCAo&AO 

= 

locs(A0)  U  locsCAO 

locs(A0  ®  Ai) 

= 

locs(Ao)  U  locs(Ai) 

locs(3/.A) 

= 

locs(A) 

locs(V/.A) 

= 

locs(A) 

locs(3X  <:  Aq.AO 

= 

locs(A,{A0/X}) 

locs(VX  <:  Aq-Aj) 

= 

locsCA.fAo/X}) 

locs(A0  =>  Ai) 

= 

locs(Ao) 

locs(A0;Ai) 

= 

locs(Ao) 

locs(none) 

= 

0 

locs(P) 

= 

0 

locs(X[Z7]) 

= 

0 

locs((rec  X(w).A)[t7]) 

= 

locs(A{rec  X(u).A/X}{U /u}) 
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If  the  type  is  a  protocol,  we  do  not  yield  a  location  since  we  will  have  to  lock  that  protocol’s 
locations  separately  (i.e.  locking  is  “shallow”).  Recursive  types  are  assumed  to  be  non-bottom  so 
that  there  is  a  finite  number  of  unfolds  that  are  relevant  to  extract  the  set  of  locations. 


G.3  Store  Typing 

riAh/i 


Store  typing,  (str:*) 


(str:Loc) 

H  A  \-H 


(str:Subsumption) 
f  |  A(,  h  H  r  h  A0  <:  A | 


(str:Binding) 

r  I  A,  Av  h  H  r  I  Av  h  V  :  A  H  • 


T,p  :  loc  |  A  h  H  r  I  Ai  h  H 


r  |  A,  rw  p  A  h  H,  p  ^  v 


(str:Empty) 


(str:Locked) 

r  |  A0  h  H' ,  p  c — >  v 


locs(A0)  =  Iocs  (A  j )  =  p 

r|  A,  h  H",p  ^  V '  r|  A,A2  h  H,H",p  ^  V' 


r  |  A,  A0,  Aj;A2  I-  H,H' ,p*  e— »  v 


(str:Dead-Locked) 

Iocs  (A  | )  =  p 

r|Ai  h  H",p  ^  v 7  r|  A,A2  h  H,  H",p  ^  v' 

n  A,  Ai;A2  h  H 

(str:ForallLocs)  (str:ForallTypes) 

r,  / :  loc  |  A,  A  b  H  Y,X  :  type,X  <:  A0  |  A,  A]  h  H 

r|A,V/.Ah//  T  |  A,VX  <:  Ao-Ai  h  H 

(where  /,  X  are  fresh  in  the  conclusion) 
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G.4  Substitution 


Definition  3  (Substitution).  For  clarity,  we  define  substitution  on  constructs  using  e  even  though 
the  grammar  will  restrict  these  “expression”  to  be  values  (v)  in  some  of  those  places.  This  is  done 
just  for  readability  purposes  to  make  it  clear  which  value  is  being  used  for  the  substitution,  and 
where  it  is  being  substituted  into. 

1.  Variable  Substitution,  (vs:*) 

We  define  the  usual  capture-avoiding  (i.e.  up  to  renaming  of  bounded  variables)  substitution 
rules: 


c0{v/4  =  ex 


(vs:l) 

p{v/.r} 

(vs:2) 

x{vlx) 

(vs:3) 

XoJv/.Vj} 

(vs:4) 

{Ax0.eo){v  1  xx) 

(vs:5) 

{f  =  e}{v/x} 

(vs:6) 

(e.f ){v/4 

(vs:7) 

(e0  ex ){v/x} 

(vs:8) 

(new  e){v/.r} 

(vs:9) 

(delete  e){v/.r} 

(vs:  10) 

(!e){v/4 

(vs:  11) 

(e0  :=  ex ){v/x} 

(vs:  12) 

(t  #e){vlx) 

(vs:13) 

(case  e  of  t j#Xj  ->  e-,  end){v/x} 

(vs:  14) 

(let  x0  =  <?0  in  e{  end){v/xi} 

(vs: 15) 

(lock  e){v/x} 

(vs:  16) 

(unlock  e){v/x} 

(vs:  17) 

(fork  e){v/x} 

P 

v 

X0  (x0  Xi ) 

Ax0.e0{v/x  1}  (x0  ±  *1) 

{f  =  e{v/x}} 

e{v/x}.£ 

eo{v/x}  ex  {v/x} 

new  e{v/x} 

delete  <?{v/x} 

\e{vlx\ 

eo{v/x}  :=  ex {v/x} 
t#e{v/x} 

case  e{v/x}  of  t ,#x;-  — >  <?/{v/x)  end  (x,  x) 
let  xo  =  eo{v/x  1}  in  e\{v/x  1}  end  (xq  ±  x\) 

lock  e{vlx\ 
unlock  e{vlx) 
fork  e{v/x} 
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2.  Location  Variable  Substitution,  (ls:*) 

Similarly,  we  define  location  substitution  (but  here  up  to  renaming  of  bounded  location  vari¬ 
ables)  as: 


A0{p/l}  =  Ai 


(ls:2.1) 

p{p/l) 

(ls:2.2) 

l{p/l } 

(ls:2.3) 

loip/h) 

(ls:2.4) 

QA){p/l} 

(ls:2.5) 

(A0  -o  A{){pll] 

(ls:2.6) 

(A0  ::  A\){p/l} 

(ls:2.7) 

[f  :  A]{p/l} 

(ls:2.8) 

(VZ0.A){p/Z  i} 

(ls:2.9) 

(3l0.A){p/h} 

(ls:2.10) 

(ref  p0){pi/l} 

(ls:2.12) 

(rw  pq  A){pi  //} 

(ls:2.13) 

(A0  *  A{){pjl} 

(ls:2.14)  (VX  <:  Ao-AOjp//} 

(ls:2.15)  (3X  <:  Ao-AOIp//} 

(ls:236) 

(X[U]){p  / 1} 

(ls:237)  ((rec  X(u).A)[U]){p/l} 

(ls:238) 

(Zi  ti#At){p/l} 

(ls:239) 

(A0  ©  A  j ){/?//} 

(ls:2.20) 

none{p//} 

(ls:2.21) 

(A0  =^>  AOjp//} 

(ls:2.22) 

(AoMlp/l) 

(ls:2.23) 

(A0  &  A  i ){/?/ /} 

(ls:2.24) 

top{p//} 

r  0{p/i)  =  r. 

(ls:33) 

•{p/Z} 

(ls:3.2) 

(r,x:A){p//} 

(ls:3.3) 

(T,Z0  :  loc){p/Zi} 

(ls:3.4) 

(r,X  <:  A){p/l} 

(ls:3.5) 

(T,X  :  *){p/Z} 

=  P 
=  P 

-  lo  do  =£  h) 

=  \A{pH) 

=  A0{p/l}  -o  Axip/l} 

=  A0{p/l}  ::  Ai{p/l} 

=  [f  :A{p/l)] 

-  V/q.A{/?//i}  (/0  =£  /i) 

=  3/0.A{p//i}  (Zo^ZO 

=  ref  po{pi/l} 

=  rwpoipi//}  A{pi/Z} 

=  A0{p/l}  *Al{p/l} 

=  VIcAofWZliJWZ} 

=  BXcAoip/DAAp/l} 

=  *[£/{/>//}] 

=  (rec  V(M).A{p//})[f/{/7//}]  (/  g  u) 

=  X/  t,#A,{/?//( 

=  A0{p//}  ®Ai{p/Z} 

=  none 

=  A0{p/l}  Aiip/l} 

=  A0{p  1 1}  \  A\{p  1 1} 

=  A0{p/Z}  &  Ai{p//} 

=  top 


=  Y{p/l},x  \  A{p/l} 

=  r{p//i),/0  :  loc  do^h) 
=  r{p//},X<:A{p//} 

=  r  {p/l},X:k 


A0{  p/l}  =  Aj 

(ls:4.1)  -{p/Z}  =  • 

(ls:4.2)  (A,  ^  :  A){p/l}  =  A  {p/l},  x  :  A{p/l} 
(ls:4.3)  (A,  A){p/Z}  =  A  {p/l},A{p/l} 
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3.  Type  Variable  Substitution,  (ts:*) 

Finally,  we  define  type  substitution  (up  to  renaming  of  bounded  type  variables)  as: 


A0{A1/X}=A2 


(ts:2.1) 

(ts:2.2) 

(ts:2.3) 

(ts:2.4) 

(ts:2.5) 

(ts:2.6) 

(ts:2.7) 

(ts:2.8) 

(ts:2.9) 

(ts:2.10) 

(ts:2.  11) 

(ts:2.13) 

(ts:2.14) 

(ts:2.15) 

(ts:2.16) 

(ts:2.17) 

(ts:2.18) 

(ts:2.19) 

(ts:2.20) 

(ts:2.21) 

(ts:2.22) 

(ts:2.23) 

(ts:2.24) 


p{A/X} 
_  1{A/X } 
(X[U]){A/X) 
(V0[f J]){A/Xx} 
(!A0){A1/X} 
(A„  -o  Ay){A2/X } 
(A0  ::  Aj){A2/V} 
[f :  A]{A0/X} 
(V/.A0){Ai/X} 
(3/.A0){Ai/V} 
(ref  p){A/X} 
(rw  p  A0){Ai/X} 
(A0  *  Ai){A2IX) 


none{A/X} 
(A0  =>  Ay){A/X) 
(A0;A1){A/V} 
(A0&A1){A/V) 
top{A/X} 


(Wo  <:  A2.Ao){A1/X1} 
(3X0  <:  A2.Ao){A1/X1} 
((recVo  (u).A0)[U]){Al/X1} 
CZ/t;#A,){A/X) 
(A0  ®  A^fA/X} 


r0{A/V}  =  Ty 


(ts:3.1)  -{A/X}  = 

(ts:3.2)  (r,x:A0){A1/X}  = 

(ts:3.3)  (r,  / :  loc){A/X}  = 

(ts:3.4)  (r,X0<:A0){A1/X1}  = 

(ts:3.5)  (T,X0:k){Al/Xl}  = 


A  0{A/X}  =  Ay 


P 

l 

A[U[AjX}] 

X0  [U{A/Xy\]  (X0*Xy) 

lAo{Ay/X} 

A0{A2/X}  -o  A,{A2/X} 

Aq{A2/X}  ::  Ay{A2/X) 

[f :  A{A0/X}] 

V/A0{A,/X) 

3/.A0{Ai/X} 
ref  p 

rw  p  A0{Ai/X} 

A0{A2/X}*A1{A2/X} 

VXo  <:  A2{A1/X1}.A0{A1/X1}  W)  *  X,) 

3X0  <:  A2{A1/X1}.A0{A_l/X1}  (X0  4  X,) 

(rec  X0(M).A0{A1/X1})[f/{A1/X1}]  (X0  4X,,X,  £  w) 
Z/  t,#A,{A/X) 

A0{A/X}®Ay{A/X} 

none 

A0{A/X}  =>  Ai{A/X} 

A0{A/X};  Aj{A/X} 

A0{A/X}&Ay{A/X} 

top 


T{Ay/X},x:A0{Ay/X} 
r{A/X},  / :  loc 

HAi/X^Xo  <:  AofAi/Xi)  (X0  4  Xj) 
rfAj/X^Xo  :  A:  (X0  4  X,) 


(ts:43)  -{A/X}  =  • 

(xs:4.2)  (A,x  :  A0){A1/X}  =  A {Ax/X},  jc  :  A0{A,/X| 
(ts:4.3)  (A,Ao){A1/X}  =  A{Aj/X},  A0{Aj/X} 
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H  Main  Theorems 

H.l  Subtyping  Lemmas 

Lemma  11  (Subtyping  Inversion).  We  have  the  following  cases  for  types  (A)  and  for  the  linear 
typing  environment  (A): 

•  (Type) If  T  b A  <:  A!  then  one  of  the  following  holds  (omitting  congruence  rules): 

1.  A  =  A'. 

2.  if  A  =  !A0  then  either: 

(a)  A'  =  Ai  and  T  b  A0  <:  Ai  ,  or; 

(b)  A'  =  \A{  and  T  b  A0  <:  Ax  ,  or; 

(c)  A'  =  ![]. 

3.  if  A  =  A0  Ai  then  A'  -  A2  A3  and  T  b  Ai  <:  A3  and  T  b  A2  <:  A0. 

4.  if  A  =  A0  ::  A2  then  A'  =  A\  ::  A3  and  T  b  A0  <:  Ai  and  T  b  A2  <:  A3. 

5.  if  A  =  [f  :  A]  then  either: 

(a)  A  =  [f  :  A,  f"  :  A"]  and  A'  =  [f  :  B]  and  [f  :  A]  *  0  and  T  b  [f  :  A]  <:  [f  :  5], 

(b)  A  =  [f  :  A,  f"  :  A0]  and  A'  =  [f  :  A,  f"  :  fi„J  and  T  b  A0  <:  fi0  and 

T  b  [f  :  A]  <:  [f  :  5], 

6.  if  A  =  rw  p  A0  then  A'  =  rw  p  A\  and  T  b  A0  <:  A\. 

7.  if  A  =  3/.A0  then  A'  =  3/.A!  and  T.  I :  loc  b  A0  <:  Ax. 

8.  if  A  =  V/.A0  then  either: 

(a)  A'  =  Vl.Ax  and  T,  / :  loc  b  A0  <:  Ax,  or; 

(b)  A'  =  Ax{p/l}  and  T, l :  loc  b  A0  <:  Ax. 

9.  if  A  =  3A<:A3.Ao  then  A'  =  3X<:A3.Ai  and  T, X  :  type,X  <:  A3  b  A0  <:  Aj. 

10.  if  A  =  VX<:A3.A()  then  either: 

(a)  A'  =  VX<:A3.Ai  and  T,X  :  type,X  <:  A3  b  A0  <:  Ai,  or; 

(b)  A'  =  A'0{A2/X}  and  T  b  A2  <:  A,  and  T,X  :  type,X  <:  A3  b  A0  <:  A'Q. 

11.  if  A=Aq*Ax  then  A' =  A0  *  A2  and  T  b  Ax  <:  A2. 

12.  if  A  =  2;  t i#A;  then  A!  -  X,  and  77  <  m  and  T  b  A,  <:  Bj. 

13.  if  A  =  Aq&A]  then  A'  -  A2  and  T  b  A0  <:  A2. 

14.  A' =  A®  A"  and  T  b  A  <:  A". 

15.  A'  =  top. 

16.  A'  =  3 l.Ao{l/p}  and  T  b  A  <:  A0. 

17.  A'  =  3X<:  AiA0{X/A2)  and  T  b  A2  <:  A!  and  T  b  A  <:  A0. 
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18.  A  =  X  and  X  <:  A0  e  T  and  T  b  A0  <:  A'. 

19.  T  =  F',F  and  F  b  A  <:  A' 

•  (Delta)  If  T  b  A  <:  A'  then  one  of  the  following  holds: 

1.  A  =  A'. 

2.  if  A  =  Ao,;t:Ao  then  A' =  Ai,jc  :  Ai  and  T  b  A0  <:  Ai  and  TbAo<:Ai. 

3.  if  A  =  A(),A0  then  A'  =  Ai,Ai  and  T  b  A()  <:  Ai  and  T  l-  A0  <:  A\. 

4.  if  A  =  Ao,A(),Ai  then  either: 

(a)  A'  =  A',,  A'  *  A\  and  Y  b  A0,A0,Ai  <:  A',,  A',,  A',  or; 

(b)  case  (3)  with  A0,  or; 

(c)  case  (3)  with  Ai. 

5.  if  A  =  A(),A0*Ai  then  A' =  A [VA'0,A\  and  Y  b  A0,  A0  *  A\  <:  Aq,  A'0  *  A\. 

6.  if  A  =  A0,none  then  A' =  A!  and  Y  b  A0  <:  Ai. 

7.  A'  =  A0,  none  and  Y  b  A  <:  A0. 

8.  if  A  =  A(),Ao  ©  Ai  then  Y  h  A0,Ao  <:  A'  and  Y  b  A0,Ai  <:  A'. 

9.  if  A'  =  Ai,A0&Ai  then  Y  b  A  <:  Ai,A0  and  T  b  A  <:  Ai,Ai. 

10.  if  A  =  A o,A0  and  A'  =  X\,Ai,A2  then  Y  b  A()  <:  Aj  and  T  b  A0  ^  Aj  ||  A2. 

Proof.  The  proof  is  straightforward  by  induction  on  the  subtyping  derivation. 

□ 

Lemma  12  (Subtyping  Transitivity).  We  have  that: 

•  If  T  b  A0  <:  Ai  and  Tb  Ai  <:  A2  then  T  b  A0  <:  A2. 

•  If  T  b  A0  <:  Ai  and  T  b  Ai  <:  A2  then  T  b  A0  <:  A2. 

Proof.  The  proof  is  straightforward  by  induction  on  the  derivation  of  sub  typing.  Note  that  transi¬ 
tivity  for  (sd:Share)  requires  the  subtyping  extension  on  composition.  □ 

H.2  Store  Typing  Lemmas 

Lemma  13  (Store  Typing  Inversion).  If 

T|  A  b  H 

then  one  of  the  following  holds: 

1.  T  =  •  and  A  =  •  and  H  - 
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2.  if  r  =  r,p  :  loc  then  F  |  A  h  H. 

3.  T  h  A'  <:  A  and  T  |  A'  h  H. 

4.  if  A  =  A',  rw  p  A  and  H  =  H',p  t— >  v  then  Y  \  A',  Av  h  H'  and  Y  |  Av  l-  v  :  A  H  •. 

5.  if  A  =  A ',  A0,  Ap  A2  and  H  =  H',p‘  v  then  locs(A0)  =  locs^)  =  p  and 
r  |  A0  h  p  v  and  TIAihp^v'  and  T  |  A',  A2  I-  H',p  V. 

6.  if  A  =  A',  ApA2  then  locs(A!)  =  p  and  p  v  i  H  and  Y  \  A\  h  p  v'  and 
Y\A',A2  h  H,p  ^  V'  . 

7.  if  r  I  A,V/.A  h  H  then  Y,l :  loc  |  A,  A  h  H. 

8.  if  r  |  A,VA  <:  A". A  h  H  then  Y,X  :  type,X  <:  A"  \  A, A  h  H. 

Proof.  Straightforward  induction  on  the  derivation  of  T  |  A  h  H.  □ 

Lemma  14  (Protocol  Store  Typing).  If  we  have: 

Iocs(Aq)  —  p  T  |  A0  h  H  p  z — >  v  6  H  r  l-  A0  ^  A\  ||  A2 

then  each  choice  (&)  of  A{  and  A2  must  include  an  alternative  (©)  such  that  its  rely  type  is  A0.  I.e.: 

A0  6  relyCAO  A0  6  rely(A2) 

where: 

rely(P0&^i)  =  rely(P0)  if  rely(P0)  =  rely^) 

rely(  P()  ®  P{  )  =  rely(P0)  U  relyCPO 
rely(  A  =>  P  )  =  {A} 

Proof.  Straightforward  by  protocol  composition.  We  know  that  by  the  conditions  for  protocols  to 
be  well-formed  that  only  one  alternative  (©)  can  exists  for  a  given  rely  type.  Thus,  only  one  such 
alternative  can  rely  on  A0.  Likewise,  we  have  that  any  choice  (&)  must  itself  confirm  with  the  state 
of  the  shared  state.  Thus,  whenever  the  shared  locations  are  shared  they  must  respect  the  rely  type 
of  all  the  protocols  that  are  sharing  that  state.  □ 


85 


H.3  Values  Inversion  Lemma 


Lemma  15  (Values  Inversion).  If  v  is  a  value  such  that 

r  |  A  h  v  :  Aq  h  • 

then  one  of  the  following  holds: 

1.  if  Aq  =  ![]  then: 

A  =  •  r|  •  h  v  :  ![]  h  • 

2.  if  A0  =  !A !  then: 

A  =  •  F  |  -  1-  v  :  At  H  • 

3.  if  Aq  =  Ai  ::  A2  then: 

r  |  A  h  v  :  A\  H  A2 

4.  if  Aq  =  ref  p  then: 

v  =  p  p  :  loc  6  T  A  =  • 

5.  if  A0  =  A  -o  A'  then: 

v  =  Ax.e  T  |  A,  x  :  A  h  c  :  A'  h 

6.  if  A0  =  V/.A  then: 

T,  / :  loc  |  A  h  v  :  A  H  • 

7.  if  A0  =  3/. A  then: 

T  |  A  h  v  :  A{p//}  H  • 

8.  if  Aq  =  [f  :  A]  then: 

< 

II 

Hh 

II 

> 

T 

_L 

(Note:  the  record  value  can  have  more  fields  than  those  listed  in  the  type  but  only  the  fields 
in  the  type  will  be  known  by  inversion.) 

9.  if  Aq  =  VX  <:  A'. A  then: 

T,  X  :  type,  X  <:  A'  |  A  h  v  :  A  H  • 

10.  if  A()  =  3X  <:  A'. A  then: 

T  |  A  h  v  :  A{A'/X}  H  • 

11.  ifA0  =  X,  ti#Aj  then: 

v  =  t/#V;  T  |  A  h  v,-  :  Aj  h  • 

for  some  /. 
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12.  if  A0  =  (rec  X(u).A)[U\  then: 


r  |  A  h  v  :  A  {rec  X(u).A/X}{U /u]  H  • 


13.  if  A  =  A',Ai  ©  A2  then: 


r  |  A',  A[  I-  v  :  A0  h  •  r|  A',A2  h  V  :  A0  h  • 


14.  if  A0  =  A!  ©  A 2  then  either: 

r|Ahv:AiH-  or  T  |  A  h  v  :  A2 -I  • 


15.  if  A0  =  top  then: 

F  |  A  l-  v  :  A{  H  • 

(Note:  the  remaining  types,  such  as  &,  do  not  appear  in  this  lemma  since  they  are  related  to 
capabilities,  not  values,  and  therefore  cannot  be  used  to  directly  type  some  value — i.e.  they  can  get 
stacked  on  top  of  some  other  type,  but  not  be  used  to  type  the  value  itself). 

Proof.  By  induction  on  the  derivation  of  T  |  A  h  v  :  A0  H  •. 

Case  (t:Ref)  -  We  have: 

T,p  :  loc  |  •  h  p  :  ref  p  H  • 

Thus,  we  conclude  by  case  4  of  the  definition 

Case  (t:Pure)  -  We  have: 

T  |  •  i-  v  :  !Ai  h  • 

T  |  •  h  v  :  Ai  H  • 

Thus,  we  conclude  by  case  2  of  the  definition 
Case  (t:Unit)  -  We  have: 

T  |  •  h  v  :  ![]  H  • 

Thus,  we  conclude  by  case  1  of  the  definition 

Case  (t:Pure-Read),  (t:Linear-Read),  (t:Pure-Elim),  (t:New),  (t:Delete),  (t:Assign), 
(t:Dereference-Linear),  (t:  Dereference-Pure)  -  Not  applicable. 


(1) 

by  hypothesis. 


(1) 

by  hypothesis. 

(2) 

by  inversion  on  (t:Pure). 


(1) 

by  hypothesis. 
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Case  (t:Record)  -  We  have: 

r|Ah{f^}:[f7A]H-  (1) 

by  hypothesis. 

r  |  A  h  Vi  :  Af  h  •  (2) 

by  inversion  on  (t:Record). 

Thus,  we  conclude  by  case  8  of  the  definition. 

Case  (t:Selection),  (t: Application)  -  Not  applicable. 

Case  (t:Function)  -  We  have: 

T  |  A  h  Ax. 6  :  A0  — o  A.  i  H  •  (1) 

by  hypothesis. 

T  |  A,a  :  A0  h  e  :  Aj  H  •  (2) 

by  inversion  on  (t:Function). 

Thus,  we  conclude  by  case  5  of  the  definition. 

Case  (t:Cap-Elim),  (t: Cap-Unstack),  (t: Application)  -  Not  applicable. 

Case  (t: Cap-Stack)  -  We  have: 

T|  A  h  v  :  A0  ::  Ay  H  •  (1) 

by  hypothesis. 

T  |  A  h  v  :  A()  h  A,  (2) 

by  inversion  on  (t:Cap-Stack). 

Thus,  we  conclude  by  case  3  of  the  definition. 

Case  (t:Forall-Loc-Val)  We  have: 

T  |  A  h  v  :  V/.A  H  •  (1) 

by  hypothesis. 

T,  l :  loc  |  A  h  v  :  A  h  •  (2) 

by  inversion  on  (t:Forall-Loc-Val)  with  (1). 

Thus,  we  conclude  by  case  6  of  the  definition. 

Case  (t:Forall-Type-Val)  We  have: 

T  |  A  h  v  :  VX  <:  A'.A  H  •  (1) 

by  hypothesis. 

T,  X  :  type,  X  <:  A'  |  A  h-  v  :  A  H  •  (2) 

by  inversion  on  (t:Forall-Loc-Val)  with  (1). 

Thus,  we  conclude  by  case  9  of  the  definition. 
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Case  (t:Tag)  We  have: 


r  |  A  b  t#v  :  t#A  h  •  (1) 

by  hypothesis. 

r  |  A  b  v  :  A  h  •  (2) 

by  inversion  on  (t:Tag). 

Thus,  we  conclude  by  case  1 1  of  the  definition. 

Case  (t:Case)  Not  applicable. 


Case  (t:Alternative-Left)  We  have: 


T  |  A,  Aq  ©A|  h  v  :  A  2  H  * 


T  |  A,  Ao  h  v  :  A2  H  • 

T  |  A,  Aj  h v  :  A2  H * 

Thus,  we  conclude  by  case  13  of  the  definition. 


(1) 

by  hypothesis. 

(2) 

(3) 

by  inversion  on  (t: Alternative-Left). 


Case  (t:Frame)  Only  case  is  when  A  environment  on  the  right  is  not  empty  which  is  immediate 
by  applying  the  induction  hypothesis. 


Case  (t:TypeOpenBind),  (t:TypeOpenCap),  (t:LocOpenBind),  (t:LocOpenCap)  -  Immediate  by  ap¬ 
plying  the  induction  hypothesis. 


Case  (t: Subsumption)  We  have: 

(1) 

by  hypothesis. 

(2) 

(3) 

(4) 

(5) 

by  inversion  on  (t: Subsumption). 

Remember  that  we  are  showing  that  (1)  obeys  the  definition  above. 

By  applying  the  induction  hypothesis  on  (3)  we  have  that  one  of  the  following  holds: 

1.  if  A0  =  ![]  then: 


T  |  A  h  v  :  A\  h  • 

TtAc  A' 

T  |  A'  b  v  :  A0  H  • 
T  b  A0  < :  A  ] 

T  b  •  <:  • 
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A'  =  • 

(1.1) 

T  •  h  v  :  ![]  h  • 

(1.2) 

r  h  ![]  <:  A\ 

(1.3) 

by  case  1  of  the  hypothesis  and  rewriting  (4). 

Then,  by  (Subtyping  Inversion)  on  (1.3)  we  have  that  either: 
•[1/2 <c)]  A[  =![] 

we  conclude  as  case  2  of  the  definition. 

(1.5) 

•  [14]  A!  =  ![]  ©  A' 

we  conclude  as  case  14  of  the  definition  using  (3). 

(1.6) 

•  [15]  A!  =  top 

we  conclude  as  case  15  of  the  definition  using  (3). 

(1.6) 

Similarly,  sub-cases  [16]  and  [17]  are  immediate  by  cases  10  and  7  of  the  definition. 

2.  if  A0  =  !A  then: 

A'  =  • 

(2.1) 

T  |  •  h  v  :  A  H  • 

(2.2) 

T  h  !A  <:  A! 

(2.3) 

by  case  2  of  the  hypothesis  and  rewriting  (4). 

by  (Subtyping  Inversion)  on  (2.3)  we  have  that  either: 

•  [1]  A!  =  !A 

Thus,  we  conclude  by  case  2  of  the  definition  through  (2.2). 

•  [2(a)]  Aj  =  A 

Thus,  we  conclude  by  induction  hypothesis  on  (2.2). 

•  [2(b)]  A!  =  !A'  and  T  h  A  <:  A' 

T  |  •  h  v  :  A'  h  • 

(2.4) 

by  (t: Subsumption)  on  (2.2)  with  T  h  A  <:  A'. 

Thus,  we  conclude  by  case  2  of  the  definition  with  (2.4). 

•  [2(c)]  A\  =  ![] 

T|- hv  :![]-)  • 

(2.5) 

by  (t:Unit)  on  v. 

Thus,  we  conclude  by  case  2  of  the  definition. 

•  [14]  A!  =  !A  ©A' 

and  we  conclude  as  case  14  of  the  definition  using  (3). 

(2.6) 

Similarly,  sub-cases  [15],  [16]  and  [17]  are  immediate  by  cases 
definition. 

15,  10,  and  7  of  the 

3.  if  A0  =  A  -o  A'  then: 

v  =  Ax.e 

(3.1) 

T  |  A,  x  :  A  l-  e  :  A'  H  • 

(3.2) 

T  h  (A  -o  A')  <:  Ai 

(3.3) 

by  case  5  of  the  hypothesis  and  rewriting  (4). 
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by  (Subtyping  Inversion): 

(Note:  we  omit  the  remaining  cases  since  they  are  straightforward) 

A\  =  A"  -o  A’”  (3.4) 

T  h  A'  <:  A"'  (3.5) 

T  h  A"  <:  A  (3.6) 

by  (Subtyping  Inversion)  on  (3.3)  we  have  that: 
r  |  A,  .r  :  A  h  e  :  A'"  H  •  (3.7) 

by  (t: Subsumption)  on  (3.2)  and  (3.5) 
H  A,*  :  A"  h  e  :  A’"  h  •  (3.8) 

by  (t: Subsumption)  on  (3.7),  (3.6)  and  (sd:Var)  with  (2). 
Thus,  with  (3.8)  and  (3.1)  we  conclude  by  case  5  of  the  definition. 

4.  if  A0  =  A  ::  A'  then: 

T  |  A'  h  v  :  A  H  A'  (4.1) 

T  h  A  ::  A'  <:  Ax  (4.2) 

by  case  3  of  the  hypothesis  and  rewriting  (4). 
by  (Subtyping  Inversion)  on  (4.2)  we  have  that: 

(Note:  we  omit  the  remaining  cases  since  they  are  straightforward) 

A\  =  A"  ::  A'"  (4.3) 

T  h  A  <:  A"  (4.4) 

T  h  A'  <:  A"’  (4.5) 

T  |  A  h  v  :  A"  H  A"'  (4.6) 

by  (t:Subsumption)  on  (4.1)  with  (4.4)  and  (4.5). 
Thus,  we  conclude  by  case  3  of  the  definition. 


5.  if  A0  =  [f  :  A]  then: 

v  =  {f^7}  (5.1) 

T  |  A'  h  v\  :  A,-h  •  (5.2) 

T  h  [f  :  A]  <:  Ax  (5.5) 

by  case  8  of  the  hypothesis  and  rewriting  (4). 
by  (Subtyping  Inversion)  on  (5.5)  we  have  that  either: 

(Note:  the  remaining  [1],  [14],  [15],  [16],  [17]  cases  are  straightforward) 

•  [5(b)]  A0  =  [f  :  A  ,  £'  :  A']  and 

Ai  =  [£?A  ,  f'  :  A"]  (5.6) 

ThA'c  A"  (5.7) 

Thus,  by  (t: Subsumption)  on  (5.2)  and  (5.7)  we  conclude  by  case  8  of  the  definition. 

•  [5(a)]  A0  =  [£7A,  £'  :  A]  and 
A]  =  [f  :  A]  and  Ax  ^  0. 
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Thus,  by  (t:Record)  with  (5.1)  and  ignoring  the  dropped  field,  we  conclude  by  case  8 
of  the  definition.  Note  that  all  fields  have  the  same  effect  and  by  i  >  0  we  ensure  that 
subtyping  leaves  at  least  one  field  to  do  such  effect. 

6.  if  Aq  =  3 l.A  then: 


T  |  A'  b  v  :  A{p/l}  H  •  (6.1) 

T  b  3 LA  <:  A\  (6.2) 

by  case  7  of  the  hypothesis  and  rewriting  (4). 
by  (Subtyping  Inversion)  on  (6.2)  we  have  that: 

A,  =  3/.A'  (6.4) 

T  b  A  <:  A'  (6.5) 

T  |  A  b  v'  :  A'{p/lj  H  •  (6.6) 

by  (t: Subsumption)  on  (6.2)  and  (6.5). 


Thus,  we  conclude  by  case  7  of  the  definition. 


The  remaining  cases  are  straightforward  since  we  can  either  “pack  again”  but  that 
means  (6.1)  is  the  unpacked  type  thus  obeying  the  definition,  or  we  have  one  of  the 
cases  that  are  similar  to  those  above  such  as  [1],[14],  or  [15]. 


7.  if  A0  =  V/.A  then: 


T,/:  loc  |  A' bv:  Ah-  (7.1) 

T  b  V/.A  <:  A,  (7.2) 

by  case  6  of  the  hypothesis  and  rewriting  (4). 
by  (Subtyping  Inversion)  on  (7.2)  we  have  that: 

(Note:  the  remaining  cases  are  straightforward  and  are  omitted) 

•  [8(a)]  A!  =  V/.A'  (7.3) 

ThAcA'  (7.4) 

T,  / :  loc  |  A  h  e  :  A'  H  •  (7.5) 

by  (t: Subsumption)  on  (7.1)  and  (7.4). 
.  [8 m  Ai  =  A{p/l}  (7.6) 


Immediate  by  (Substitution  Lemma)  and  induction  hypothesis  on  (7.1). 


8.  if  A0  =  ref  p  then: 


v  —  p 

(8.1) 

p  :  loc  e  T 

(8.2) 

A  =  • 

(8.3) 

T  b  ref  p  <: 

(8.4) 

by  case  4  of  the  hypothesis  and  rewriting  (4). 
(Note:  the  remaining  [14]  is  straightforward) 
by  (Subtyping  Inversion)  on  (8.4)  we  have: 

•  [1]  Al  =  (ref p) 
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Thus,  we  conclude  by  case  2  of  the  definition. 


9.  if  A0  =  3X  <:  A' .A,  analogous  to  3 LA. 

10.  if  A0  =  VX  <:  A'. A,  analogous  to  V/.A. 

11.  if  A0  =  Yji  t/#A'  then: 


V  =  t/#Vj 

(H.l) 

T  1  A'  b  v,-  :  A'  h  • 

(11.2) 

for  some  i. 

T  b  2,-  t/#A'  <:  A\ 

(Note:  the  remaining  [1]  and  [14]  cases  are  straightforward) 
by  (Subtyping  Inversion)  on  (8.4)  we  have  that: 

(11.3) 

A!  =  t'#A'  +  ...  +  Z/t,#A' 

Thus,  by  (11.2)  we  conclude  by  case  11  of  the  definition. 

(11.4) 

12.  if  A0  =  (rec  X(u).A)[U]  then: 

T  |  A'  h  v  :  Aj  H  •  (12.1) 

T  b  (rec  X(u).A)[U]  <:  A!  (12.2) 

by  case  12  of  the  hypothesis  and  rewriting  (4). 
(Note:  the  remaining  cases  are  straightforward) 
by  (Subtyping  Inversion)  on  (12.2)  we  have: 

•  [1]  A!  =  A{rec  X(u).A/X}{U /u} 

Thus,  we  conclude  by  induction  hypothesis  on  (12.1)  combined  with  (t: Subsumption). 

13.  if  A  =  A',  A2  ©  A3  then: 


T  |  A',  A?  h  v  :  A0  H  •  (13.1) 

T  |  A',  A3  h  v  :  A„  H  •  (13.2) 

T  b  A0  <:  Aj  (13.3) 

By  induction  hypothesis  on  each  case  and  then  (t: Subsumption). 

14.  if  A0  =  A i  ©  A2  then  either: 

T  |  A'  h  v  :  Aj  H  •  (14.1) 

T  |  A'  b  v  :  A2  h  •  (14.2) 

and: 

T  b  Ai  ©  A2  <:  A'  (14.3) 
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This  case  is  analogous  to  previous  ones  by  applying  (Subtyping  Inversion)  on  (14.3) 
yielding  cases  [1]  and  [14].  The  first  is  immediate,  the  second  is  closed  by  considering 
either  (14.1)  or  (14.2)  through  (t: Subsumption). 

15.  if  Aq  =  top  then  A\  =  top  is  the  only  possibility  and  we  conclude  by  (1)  with  definition 
15. 

Case  (t:Let),  (t:Share),  (t:Lock-Rely),  (t:Unlock-Guarantee),  (t:Fork)  -  Not  values. 

□ 
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H.4  Free  Variables  Lemma 

Lemma  16  (Free  Variables).  If  T  |  A0,  x  :  A0  h  e  :  A\  H  A!  and  x  e  fv(e)  then 

where  fv(e)  =  “set  of  all  free  variables  in  the  expression  e' 

Proof.  We  proceed  by  induction  on  the  derivation  of  Y  |  A0, x  :  A0  \-  e  :  Ai  H  Aj, 

Case  (t:Ref),  (t:Pure),  (t:Unit),  (t:Pure-Read)  -  the  linear  typing  environment  is  empty. 


Case  (t:Linear-Read)  -  We  have: 

T  |  x  :  A  h  x  :  A  H  •  (1) 

A  6  fv(.v)  (2) 

by  hypothesis. 


Therefore,  we  immediately  conclude  x  £  ■. 

Case  (t:Pure-Elim)  -  We  have: 

T  |  Aq,  x  :  !A0  i-  r  :  A]  h  Ai  (1) 

X  6  fv(<?)  (2) 

by  hypothesis. 

r ,  x  :  Ao  |  Ao  v  e  :  A\  h  A|  (3) 

by  inversion  on  (t:Pure-Elim). 

a  Z  Ai  (4) 

because  x  is  in  the  linear  environment  (and  cannot  appear  duplicated  in  A’s). 
Therefore,  we  conclude. 

(Note:  case  when  x  is  not  the  one  used  in  the  (t:Pure-Elim)  rule  is  a  direct  application  of  the 
induction  hypothesis.) 


Case  (t:New)  -  We  have: 

T  |  A0,  x  :  A0  i-  new  v  :  3/.(!ref  l ::  rw  l  A)  H  A]  (1) 

x  e  fv(new  v)  (2) 

by  hypothesis. 

r  |  A0,  x  :  A0  h  v  :  A  H  Aj  (3) 

by  inversion  on  (t:New)  with  (1). 

x  e  fv(v)  (4) 

[  fv(new  v)  =  fv(v)  ] 
by  definition  of  fv  and  (2). 

a  $  Ai  (5) 

by  induction  hypothesis  on  (3)  and  (4). 

Therefore,  we  conclude. 
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Case  (t:Delete)  -  We  have: 


T  |  A0,  x  \  Aq\t  delete  v  :  31. A  h  Ai  (1) 

x  e  fv(delete  v)  (2) 

by  hypothesis. 

T  ]  A0,  x  :  A0  h  v  :  3/.(!ref  l ::  rw  l  A)  h  Ai  (3) 

by  inversion  on  (t: Delete)  with  (1). 
x  e  fv(v)  (4) 

[  fv(delete  v)  =  fv(v)  ] 
by  definition  of  fv  and  (2). 

x£Ax  (5) 

by  induction  hypothesis  on  (3)  and  (4). 

Therefore,  we  conclude. 

Case  (t:Assign)  -  We  have: 


T  I  Ao,x  :  A  h  Vo  :=  vi  :  A1  H  A2,rw  p  A0  (1) 

x  €  fv(v0  :=  vi)  (2) 

by  hypothesis. 

T  |  Aq,  x  :  A  h  Vj  :  Aq  h  A[  (3) 

T  |  Ai  h  v0  :  ref  p  H  A2,  rw  p  A\  (4) 


by  inversion  on  (t: Assign)  with  (1). 
[  fv(v0  :=  vi)  =  fv(v0)  U  fv(vO  ] 


Therefore,  we  have  the  following  possibilities: 

1.  x  e  fv(vo)  A  x  i  fv(vO 

(x  :  A)  €  Ai  (1.1) 

by  x  £  fv(vi). 

x  t  A2,rw  p  A{  (1.2) 

by  induction  hypothesis  on  (4)  with  (1.1). 
x  i  A2,  rw  p  A0  (1.3) 

since  the  capability  trivially  obeys  the  restriction  (since  x  is  not  a  type). 
Thus,  we  conclude. 

2.  X  6  fv(vi)  A  X  i  fv(v0) 

xtAx  (2.1) 

by  induction  hypothesis  on  (3)  and  case  assumption, 
x  i  A2,rw  p  A{  (2.2) 

by  (2.1)  and  (4). 

x  <£  A2,  rw  p  A0  (2.3) 

since  the  capability  trivially  obeys  the  restriction  on  (2.2). 

Thus,  we  conclude. 
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3.  X  £  fv(vo)  A  X  6  fv(Vi) 

x£Al  (3.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 

We  reach  a  contradiction  since  v0  is  well-typed  by  (4)  but  x  e  fv(vi)  contradicts  (3.1). 
Thus,  such  case  is  impossible  to  occur  in  a  well-typed  expression. 

Thus,  we  conclude. 

Case  (t:Dereference-Linear)  -  We  have: 

T  |  Aq,  v  :  Ao  I-  !v  :  A  h  Ai,rw  p  ![] 
x  e  fv(!v) 

T  |  A0,  x  :  Aq  I-  v  :  ref  p  H  Ai ,  rw  p  A 

X  6  fv(v) 
x  i  Ai,rwp  A 
x  t  Ai,rw  p  ![] 

Thus,  we  conclude. 

Case  (t:Dereference-Pure)  -  We  have: 

T  |  A0,  v  :  A0  I-  !v  :  !Aj  H  A1?rw  p  !At 
x  e  fv(!v) 

T  |  A0,  x  :  A0  h  v  :  ref  p  H  Ai,  rw  p  !Ai 

x  e  fv(v) 
x  i  Ai, rw  p  !Ai 
Thus,  we  conclude. 

Case  (t:Record)  -  We  have: 

T  |  A,  x  :  A0  h  {f  =  v}  :  [f  :  A]  H  •  (1) 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Dereference-Pure). 

[  fv(!<?)  =  fv(v)  ] 

(4) 

by  definition  of  fv  and  (2). 

(5) 

by  induction  hypothesis  on  (3)  and  (4). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Dereference-Linear). 

[  fv(!v)  =  fv(v)  ] 

(4) 

by  definition  of  fv  and  (2). 

(5) 

by  induction  hypothesis  on  (3)  and  (4). 

(6) 

by  (5)  and  since  a  cannot  be  in  rw  p  ![]. 
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16  fv({f  =  V}) 

Therefore,  we  immediately  conclude  x  £  ■. 

Case  (t:Selection)  -  We  have: 

T  |  A0,  x  :  Aq  l-  v.f)  :  A,-  H  A] 
a'  e  fv(v.f) 

T  ]  Ao,  a  :  A0  I-  v  :  [f  :  A]  H  Ai 

X  G  fv(v) 

X  i  Ai 

Thus,  we  conclude. 

Case  (t: Application)  -  We  have: 


(2) 

by  hypothesis. 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t: Selection). 

[  fv(v.f)  =  fv(v)  ] 

(4) 

by  definition  of  fv  and  (2). 

(5) 

by  induction  hypothesis  on  (3)  and  (4). 


T  |  A0,  a  :  A  h  vo  Vi  :  Ai  h  A2 

A  G  fv(Vo  Vi) 


T  |  A0  |-  Vo  :  A ( )  — o  A[  h  A] 
T  |  Aj  l—  :  A ( )  h  A2 


(1) 

(2) 

[  fv(v0  Vi)  =  fv(Vo)  U  fv(vi)  ] 
by  hypothesis. 

(3) 

(4) 

by  inversion  on  (t: Application)  with  (1). 


Therefore,  we  have  the  following  possibilities: 

Tag  fv(vO  A  a  i  fv(v0) 

T  |  A0  l-  Vo  :  A0  -oAj  H  A)  (1-1) 

Aj  =  Aj,  a  :  A  (1.2) 

by  a  i  fv(v0). 

T  |  A'j ,  a  :  A  h  vi  :  A0  H  A2  (1.3) 

by  rewriting  (4)  with  (1.2). 

a  i  A2  (1.4) 

by  induction  hypothesis  on  (1.3)  and  sub-case  hypothesis. 

Thus,  we  conclude. 

2.  A  G  fv(vo)  A  A  G  fv(vi) 

a£  A,  (2.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 
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We  reach  a  contradiction  since  V\  is  well-typed  by  (4)  but  a  £  fv(vi)  contradicts  (2.1). 
Thus,  such  case  is  impossible  to  occur  in  a  well-typed  expression.  Therefore,  we  con¬ 
clude. 

3.  X  £  fv(vo)  A  X  i  fv(vi) 

xtAi  (3.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 
x£A2  (3.2) 

by  (3.1)  and  (4). 

Thus,  we  conclude. 

Case  (t:Function)  -  We  have: 


T  |  A,  x  :  A0  I-  Axo.e  :  A2  A\  H  • 
x  £  fv(Axo.e) 

x  i  ■ 

Thus,  we  conclude. 

Case  (t:Cap-Elim)  -  We  have: 

T  |  Aq,  x  :  A i  ::  A2  \-  e  :  Ao  h  Ai 
x  G  fv(e) 

T  |  A0,  x  :  A\,  A2  h  e  :  A0  H  Aj 
x  i  Ai 

Thus,  we  conclude. 

Case  (t: Cap-Stack)  -  We  have: 

T  ]  Ao,  a  :  Ao  I-  e  :  A]  ::  A2  -l  Ai 
a  G  fv(e) 

T  |  Ao  l-  e  :  A\  -l  Ai,  A2 
x  Aj ,  A2 
x  t 

Thus,  we  conclude. 


(1) 

(2) 

by  hypothesis. 

(3) 

since  it  is  the  empty  environment. 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Cap-Elim)  on  (1). 

(4) 

by  induction  hypothesis  on  (2)  and  (3). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Cap-Stack)  on  (1). 

(4) 

by  induction  hypothesis  on  (3)  and  (2). 

(5) 

by  (4). 
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Case  (t: Cap-Unstack)  -  We  have: 


r  |  Ao,  x  :  Ao  l-  e  :  A\  h  Ai,  A2 
x  e  fv(e) 

r  |  A0,  x  :  A0  l-  e  :  A\  ::  A2  H  A! 
x  <£  A 

Thus,  we  conclude. 

Case  (t:Frame)  -  We  have: 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Cap-Unstack)  with  (1). 

(4) 

by  induction  hypothesis  with  (3)  and  (2). 


T  |  (A0,  x  :  A0),  A2  h  c  :  A  h  Aj ,  A2  (1) 

X  6  fv(<?)  (2) 

by  hypothesis. 

T  ]  A0,  x  \  Aq  \-  e  \  A  -\  A\  (3) 

by  inversion  on  (t:Frame)  with  (1),  note  by  (2)  x  must  be  in  environment. 

x  A\  (4) 

by  induction  hypothesis. 

a  t  (Aj,A2)  (5) 

since  by  (1)  a  cannot  be  in  A2. 

Thus,  we  conclude. 

Case  (t: Subsumption)  -  We  have: 


T  |  A0,  a  :  A  h  c  :  Ai  H  Ai  (1) 

a  G  fv(e)  (2) 

by  hypothesis. 

T  h  A0,  a  :  A  <:  Aq,  a  :  A!  (3) 

T  |  A;,  h  e  :  A()  H  A;  (4) 

T  h  Ao  <:  A!  (5) 

T  h  a;  <:  A!  (6) 

by  inversion  on  (t:Subsumption)  with  (1). 
a  t  a;  (7) 

by  induction  hypothesis  on  (2)  and  (4). 
a  ^  Ai  (8) 


by  (6)  and  (7)  noting  the  members  of  A\  and  A'  are  the  same. 

Thus,  we  conclude. 

Case  (t:Tag)  -  We  have: 
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r  |  A0,  x  i  A0  I-  tffv  :  A[  H  A[ 
X  G  fv(t#v) 

r  |  Ao,  x  :  Aq  \-  v  \  A\  H  Ai 

x  G  fv(e) 
x  i  Ai 

Thus,  we  conclude. 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Tag)  with  (1). 

[  fv(t#v)  =  fv(v)  ] 

(4) 

by  definition  of  fv  and  (2). 

(5) 

by  induction  hypothesis  on  (3)  and  (4). 


Case  (t:Case)  -  We  have: 


T  |  A0,  x  :  A'  \-  case  v  of  t j#xj  -»  ej  end  :  A  h  A, 
x  g  fvfcase  v  of  tj#x j  ->  ej  end) 

[  fvfcase  v  of  t j#xj  — >  ej 

r  1  Aq,  a  :  A'  h  V  :  £,■  t ,#A;  H  A' 

T  |  A',  Xi  :  A,- 1-  g;  :  A  H  A] 

i<i 


(1) 

_  (2) 

end)  =  fv(v)  U  fv(<?,)  ],  for  some  i  <  j 

by  hypothesis. 

(3) 

(4) 

(5) 

by  inversion  on  (t:Case)  with  (1). 


Therefore,  we  have  the  following  possibilities: 


Lag  fv(v)  A.t^  fv(e;) 

x£A’  (1.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 
a  £  A,  (1.2) 

by  (1.1)  and  (4). 

Thus,  we  conclude. 

2.  A  i  fv(v)  A  A  G  fv(<?/) 

(a  :  A')  G  A'  (2.1) 

by  a  i  fv(e). 

a  ^  A,  (2.2) 

by  induction  hypothesis  on  (4)  and  (2.1). 

Thus,  we  conclude. 

3.  A  G  fv(v)  A  A  G  fv(<?/) 

a  ^  A|  (3.1) 


by  induction  hypothesis  on  (3)  and  sub-case  hypothesis. 
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We  reach  a  contradiction  since  v  is  well-typed  by  (4)  but  a  e  fv(<?;)  contradicts  (3.1). 
Thus,  such  case  is  impossible  to  occur  in  a  well-typed  expression. 


Case  (t:Alternative-Left)  -  We  have: 

T  |  A0,  x  :  Ao,  Aj  ©  A2  I-  6  :  A3  H  Aj 
x  6  f v(<?) 

T  |  A0,  x  :  Ao,  Ai  1-  e  :  A3  H  Aj 
T  |  Ao,  x  :  Ao,A3  1-  e  :  A3  -1  Aj 

a  i  Ai 


(1) 

(2) 

by  hypothesis. 

(3) 

(4) 

by  inversion  on  (t: Alternative-Left)  with  (1). 

(5) 

by  induction  hypothesis  with  (2)  and  (3). 


Thus,  we  conclude. 

Case  (t:Intersection-Right)  -  Analogous  to  previous  case  but  using  (t: Intersection-Right). 


Case  (t:Let)  -  We  have: 


T  |  A0,  a  :  A  h  let  x0  =  e0  in  ex  end  :  A]  h  A2 
x  e  fv(let  xq  =  e0  in  e{  end) 


T  |  A0,  x  :  A  l-  :  Ao  H  A[ 

T  |  A 1 ,  ao  :  A0  h  e\  :Aj  -1A2 


(1) 

(2) 

[  fv(let  xq  =  e0  in  ex  end)  =  fv(e0)  U  fv(ei)  ] 

by  hypothesis. 

(3) 

(4) 

by  inversion  on  (t:Let)  with  (1). 


Therefore,  we  have  the  following  possibilities: 

1.  x  e  fv(eO  A  x  i  fv(e0) 

(a  :  A)  e  Aj  (1.1) 

by  a  i  fv(e0). 

a  i  A2  (1-2) 

by  induction  hypothesis  on  (4)  with  (1.1). 

Thus,  we  conclude. 

2.  a  e  fv(eo)  A  a  e  f v(eO 

a£  A,  (2.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 
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We  reach  a  contradiction  since  e0  is  well-typed  by  (4)  but  x  e  fv(<?,)  contradicts  (2.1). 
Thus,  such  case  is  impossible  to  occur  in  a  well-typed  expression. 

3.  x  e  fv(e0)  fv(ei) 

x£A\  (3.1) 

by  induction  hypothesis  on  (3)  and  case  assumption. 
x<t  A2  (3.2) 

by  (3.1)  and  (4). 

Thus,  we  conclude. 

Case  (t:Fork)  -  We  have: 

T  |  A0,  x  :  A0  i-  fork  e  :  ![]  h  • 
x  6  fv(e) 

x  £  • 

Thus,  we  conclude. 

Case  (t:Lock-Rely)  -  We  have: 


T  |  A0, x  :  A0,  A]  =>  A2  1-  lock  v  : ![]  -1  Ao,  Ai, A2  (1) 

x  6  fv(lock  v)  (2) 

by  hypothesis. 

T  |  •  h  v  :  ref  p  H  •  (3) 

P  e  Ao  (4) 


by  inversion  on  (1). 

We  have  a  contradiction  of  (3)  with  (2)  since  x  cannot  be  in  v  as  the  linear  environment  is 
empty. 

Thus,  we  conclude  since  this  case  cannot  occur. 

Case  (t:Unlock-Guarantee)  -  Analogous  to  the  previous  case. 

Case  (t:Forall-Loc-Val)  -  We  have: 

T  |  Ao,  x  :  Ao  1-  v  :  A\  H  • 

X  6  fv(v) 

A  g  • 

Thus,  we  conclude. 


(1) 

(2) 

by  hypothesis. 

(3) 

since  it  is  the  empty  environment. 


(1) 

(2) 

by  hypothesis. 

(3) 

since  it  is  the  empty  environment. 
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Case  (t:Forall-Type-Val)  -  Analogous  to  the  previous  case. 


Cases  (tiTypeOpenBind),  (t:TypeOpenCap),  (t:LocOpenCap),  (t:LocOpenBind)  -  Analogous  to 
the  previous  case  by  inversion  on  the  typing  rule  and  then  applying  the  induction  hypothesis. 

□ 


H.5  Well-Form  Lemmas 

Lemma  17  (Well-Formed  Type  Substitution).  We  have: 

•  For  location  variables'. 

1.  If  r,  /  :  loc  wf  and  p  :  loc  6  Y  then  T{p/l}  wf. 

2.  If  T,  / :  loc  b  A  wf  and  p  :  loc  e  Y  then  T{p/l)  b  A{p//}  wf. 

3.  If  T,  l  :  loc  b  A  type  and  p  :  loc  6  T  then  r{p//}  b  A{p/l}  type. 

•  For  type  variables'. 

1.  If  Y,X  <:  A0  wf  and  TbAi  type  and  T  b  Aj  <:  A0  then  TjAi/A}  wf. 

2.  If  Y,X  <:  Ao  b  A  wf  and  TbA|  type  and  Tb  A|  <:  A0  then  r{Ai/X}  b  A{Ai/X}  wf. 

3.  If  T, X  <:  A0  b  A  type  and  Y  b  Ai  type  and  Y  b  Ai  <:  Ao  then  r{Ai/X}  b 
A{A\/X]  type. 

Proof.  Straightforward  by  induction  on  the  structure  of  T,  A  and  types.  □ 

Lemma  18  (Well-Formed  Subtyping).  We  have  two  cases: 

1.  (Type)  If  T  b  A  type  and  T  b  A  <:  A'  then  Y  b  A'  type. 

2.  (Delta)  If  Y  b  A  wf  and  Y  b  A  <:  A'  then  T  b  A'  wf. 

Proof.  Straightforward  by  induction  on  the  definition  of  <:  for  types  and  linear  typing  environ¬ 
ments,  respectively.  □ 
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H.6  Substitution  Lemma 


Lemma  19  (Substitution  Lemma).  We  have  the  following  substitution  properties  for  both  expres 
sion  typing  and  type  formation: 

1 .  (Linear)  If 

T  |  A0  h  v  :  A0  H  Aj  T  |  Aj,  x  :  A0  e  :  A\  H  A2 

then 

T  |  A()  l-  e{v/x}  :  Ai  H  A? 


2.  (Pure)  If 

r  |  •  h  v  :  !A0  h  •  r,  x  :  Aq  |  Ao  h  e  :  A\  H  Aj 

then 

T  |  A()  h  e{\fx\  :  Ai  H  A] 

(note  that  due  to  the  required  pure  types,  the  A  environments  to  check  v  must  be  empty) 


3.  (Location  Variable)  If 


T,  / :  loc  |  Ao  h  e  :  A  H  Ai  p  :  ioc  6  T 

then 

T{pH)  I  A 0{p//}  h  c  :  A{p/l }  H  A x{pH) 

4.  (Type  Variable)  If 

r,X  :  type,  X  <:  A2  |  A0  h  e  :  A0  H  A]  T  h  A|  type  T  h  A\  <:  A2 

then 

UAi/X}  |  A0 {AJX}  h  e  :  AoiAJX]  H  A Mi/X} 

Proof.  We  split  the  proof  on  each  of  the  lemma’s  sub-parts: 

1.  (Linear) 


Proof  We  proceed  by  induction  on  the  typing  derivation  of  T  |  A1;  x  :  A0  h  e  :  Ai  h  A2. 

Case  (t:Ref),  (t:Pure),  (t:Unit),  (t:Pure-Read)  -  Not  applicable  due  to  empty  A  environ 
ment. 


Case  (t: Linear- Read)  -  We  have: 
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T|  Ah  v:  Ah-  (1) 

Y  \  x  :  A  \-  x  :  A  -\  ■  (2) 

by  hypothesis. 

(note  v’s  ending  environment  must  be  •  to  apply  (t:Linear-Read)). 
T  |  A  h  a{v/a}  :  A  H  •  (3) 

by  (vs: 2)  with  (1)  and  x. 

Thus,  we  conclude. 

Case  (t:Pure-Elim)  -  We  have: 

r  |  Aq  h  v  :  Aq  H  A[  (1) 

T  |  Ai, x\  :  !A2,  xq  :  Aq  h  e  :  A\  H  A2  (2) 

by  hypothesis. 

T,.*i  :  A2  |  Ai,  Ao  :  Aq  h  c  :  A\  H  A2  (3) 

by  inversion  on  (t:Pure-Elim)  with  (2). 
T,  xi  :  A2  |  A]  h  e{v/x o)  :  Aj  H  A2  (4) 

by  induction  hypothesis  on  (3)  with  (1). 
T  |  Ai,*i  :  !A2  h  <?{v/a0}  :  Ai  H  A2  (5) 

by  (t:Pure-Elim)  with  (4). 

Thus,  we  conclude. 

Case  (t:New)  -  We  have: 

r  |  Aq  h  v  :  Aq  H  A[  (1) 

T  |  A] ,  jc  :  Aq  h  new  v0  :  3/.(!ref  l ::  rw  /  AO  h  A2  (2) 

by  hypothesis. 

T  |  Ai, x  :  Ao  h  vo  :  A\  h  A2  (3) 

by  inversion  on  (t:New)  with  (2). 
r  |  Aq  h  v0{v/a}  :  A]  h  A2  (4) 

by  induction  hypothesis  with  (1)  and  (3). 
T  |  A0  h  new  v0{v/a}  :  3/.(!ref  l ::  rw  l  AO  h  A2  (5) 

by  (t:New)  with  (4). 

T  |  A0  h  (new  vq){v/x\  :  3/.(!ref  l ::  rw  l  AO  h  A2  (6) 

by  (vs:8)  with  (5). 

Thus,  we  conclude. 

Case  (t: Delete)  -  We  have: 

r  |  Aq  h  V  :  A0  H  Ai  (1) 

T  |  A],  a  :  Aq  h  delete  Vo  :  3/.Aj  h  A2  (2) 

by  hypothesis. 

T  |  Ai,  a  :  Aq  h  v0  :  3/.(!ref  / ::  rw  /  AO  H  A2  (3) 

by  inversion  on  (t:Delete)  with  (2). 
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r  |  A0  h-  v0{v/x}  :  3/.(!ref  l  ::  rw  /  AO  H  A2 
r  |  A()  h  d©l6t6  Vq{\’ / x\  '.  31. A I  H  At 
r  |  A()  h  (dGlGt©  Vq)\v / x\  ’  31. A i  H  A2 
Thus,  we  conclude. 


(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:  Delete)  with  (4). 

(6) 

by  (vs:9)  with  (5). 


Case  (t:Assign)  -  We  have: 


r  |  Aq  I-  v  :  Aq  h  Ai  (1) 

r  |  Aux  :  Aq  h  v0  :=  Vj  :  A,  H  A2,rwp  A2  (2) 

by  hypothesis. 

T  |  A, ,  x  :  Aq  h  V\  :  A?  H  A'  (3) 

T  |  A'  h  v0  :  ref  p  H  A2,  rw  p  A{  (4) 


by  inversion  on  (t:  Assign)  with  (2). 


We  have  that  either: 

(a)  .r  G  fv(vi) 

x£A’  (1.1) 

by  (Free  Variables)  on  (3). 

r  |  A'  h  v0{v/.v}  :  ref  p  H  A2,rw  p  A{  (1.2) 

since  v:  cannot  occur  in  e0  by  (1.1). 
r|  Ai  h  vi{v/4  :  A2  h  A'  (1.3) 

by  induction  hypothesis  on  (1)  and  (3). 
T  |  Ai  h  v0{v/4  :=  V]{v/x|  :  Aj  H  A2,rw  p  A2  (1.4) 

by  (t:Assign)  on  (1.2)  and  (1.3). 
r  |  Ai  I-  (v0  :=  Vi ){v/x}  :  Ai  H  A2,rw  p  A2  (1.5) 

by  (vs:ll)  on  (1.4). 

Thus,  we  conclude. 


(b)  x  $  fv(vi) 

(x  :  A0)  g  A'  (2.1) 

by  (9)  and  x  £  fv(vi). 

T  |  A"  h  v0{v/x}  :  ref  p  -\  A2,  rw  p  Ai  (2.2) 

by  induction  hypothesis  (since  it  is  applied  to  x  wherever  is  in  the 
environment)  and  where  A"  is  the  same  as  A'  without  x. 
T|Ai  hvx{v/x}:A2H  A"  (2.3) 

since  x  cannot  occur  in  e\  by  x  £  fv(ei). 
T  |  Ai  h  v0{v/x}  :=  vi{v/x}  :  Ai  H  A2,rw  p  A2  (2.4) 

by  (t:Assign)  using  (2.4)  and  (2.5). 
r  |  At  h  (v0  :=  Vi ){v/x}  :  A!  H  A2,rw  p  A2  (2.5) 
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Thus,  we  conclude. 


by  (vs:ll)  on  (2.6). 


Case  (t: Dereference-Linear)  -  We  have: 

T  Ao  l-  v  :  Ao  H  Ai 

(1) 

T  |  Aux:  A0  I-  !v0  :  Aj  H  A2,rw  p  ![] 

(2) 

by  hypothesis. 

T  |  Ai, x  :  A0  h  v0  :  ref  p  H  A2,  rw/;A| 

(3) 

by  inversion  on  (t:  Dereference-Linear)  on  (2). 

T  |  Ai  h  v0{v/x}  :  ref  p  H  A2,  rw  p  A\ 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

T  |  Aj  E  lvQ{v/x}  :  A,  H  A2,  rw  p  ![] 

(5) 

by  (t:  Dereference-Linear)  on  (4). 

T  |  Ai  h  (!v0){v/4  :  Ai  H  A2,rw  p  ![] 

(6) 

by  (vs:  10)  on  (5). 

Thus,  we  conclude. 

Case  (t: Dereference-Pure)  -  Analogous  to  (t:Dereference-Linear). 

Case  (t:Record)  -  We  have: 

T  |  Aq  I-  v  :  A0  H  A[ 

(1) 

T\Aux:A0\- {£  =  *}:  [f  :  A]  h  • 

(2) 

by  hypothesis. 

T  |  Ai,x  :  A0  h  v)  :  A,-  H  • 

(3) 

by  inversion  with  (t:Record)  on  (2). 

T  |  Ai  E  v'\v/x]  :  A,-  H  • 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

T|A1h{f  =  v'{v/4}:[£:A]H- 

(5) 

by  (t:Record)  on  (4). 

T  |  A,  h  ({ f  =  v'}){v/.v}  :  [f  :  A]  H  • 

(6) 

by  (vs:5)  on  (5). 

Thus,  we  conclude. 

Case  (t: Selection)  -  We  have: 

r  |  Ao  l-  v  :  Ao  H  Ai 

(1) 

T  |  Aj ,  x  :  Ao  E  Vo-f  :  Aj  H  A2 

(2) 

by  hypothesis. 

T  |  A],  jc  :  A0  E  vq  :  [f  :  AJ  H  A2 

(3) 

by  inversion  on  (t:Selection)  with  (2). 
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r  |  A]  h  v0{v/ x}  :  [f  :  Ax]  H  A2 


r  |  Ai  h  v0{v/x}.£  :  [f  :  AJ  H  A2 
r  |  Ai  h  (v0.f){v/4  :  [f  :  A,]  H  A2 
Thus,  we  conclude. 


(4) 

by  induction  hypothesis  on  (3)  with  (1). 

(5) 

by  (t:Selection)  on  (4). 

(6) 

by  (vs:6)  on  (5). 


Case  (t: Application)  -  We  have: 

T  |  A0  h  v  :  A0  H  A! 

T  |  A], x  :  A0  I-  Vo  Vj  :  A[  H  A2 

T  |  A  j ,  x  :  A0  h  Vo  :  A2  - °  A|  H  A( 

T  |  A'  h  V!  :  A2  h  A? 

We  have  that  either: 

(a)  x  G  fv(v0) 
x  £  A' 

T  |  A'  l-  vjv/x}  :  A2  h  A2 
T  |  Ao  h  V(){v/.v}  :  A2  — °  A|  H  A; 
r  |  A()  h  v0{v/x}  v,{v/x}  :  A,  H  A2 
T  |  A0  h  (v0  vi){v/x}  :  A]  h  A2 
Thus,  we  conclude. 


(1) 

(2) 

by  hypothesis. 

(3) 

(4) 

by  inversion  on  (t: Application)  with  (2). 


(1.1) 

by  (Free  Variables)  on  (3). 

(1.2) 

since  x  cannot  occur  in  Vi  by  (1.1). 

(1.3) 

by  induction  hypothesis  with  (1)  and  (3). 

(1.4) 

by  (t: Application)  with  (1.2)  and  (1.3). 

(1.5) 

by  (vs:7)  on  (1.4). 


(b)  x  i  fv(v0) 

(x  :  A0)  G  A'  (2.1) 

by  x  i  fv(vi). 

T  |  A"  h  vi{v/x}  :  A2  h  A2  (2.2) 

by  induction  hypothesis  where  A"  is  A'  without  x. 
T  |  A0  h  v0{v/x}  :  A2  -o  Ax  h  A"  (2.3) 

since  x  cannot  occur  in  v0  by  x  £  fv(v0)  and  (2.1). 
T  |  A0  h  v0{v/x}  V\ {v/x}  :  A,  H  A2  (2.4) 

by  (t: Application)  on  (2.2)  and  (2.3). 
T  |  A0  h  (v0  vi){v/x}  :  Ai  h  A2  (2.5) 

by  (vs:7)  on  (2.4). 
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Thus,  we  conclude. 


Case  (t:Function)  -  We  have: 

T  |  Ao  l-  v  :  Ao  H  Ai  (1) 

T  |  Aj ,  .to  :  Ao  h  Axi .e  \  A\  A?  H  •  (2) 

by  hypothesis. 

r  |  A1;  xi  :  A\, xq  :  A0  i-  e  :  A2  h  •  (3) 

*i  4  a0  (4) 

by  def.  of  substitution  up  to  rename  of  bounded  variables. 


r  I  Ai, JC1  :  A i  l-  e{\>lx}  :  A2  H  • 

T  |  A]  h  Ax\.e{vlx)  :  -o  A2  H  • 

T  |  Ai  h  (/l.vi.c){v/.v}  :  Ai  -o  A2  h  • 

Thus,  we  conclude. 

Case  (t:Cap-Elim)  -  We  have: 

r  |  Ao  l-  v  :  Ao  h  Ai, x\  :  A2  ::  A3 
r  |  Ai, x\  :  A2  ::  A3,  .Vo  :  A0  h  e  :  Aj  H  A2 

T  |  A1; x\  :  A2,  A3,  ao  :  A0  i-  e  :  Aj  h  A2 

T  |  A,,ai  :  A2,A3  1-  <?{v/.v0}  :  A]  H  A2 

T  |  Aj,ai  :  A?  ::  A3  1-  e{v/x 0}  :  A|  H  A2 

Thus,  we  conclude. 

Case  (t:  Cap-Stack)  -  We  have: 

r  |  Aq  1-  v  :  Aq  H  Ai 
T  |  Ai, x  :  Ao  I-  e  :  A|  ::  A?  h  A2 

T  |  A],  a  :  A0  1-  e  :  Aj  h  A2,  A? 

T  |  A]  h  c{v/a}  :  A]  H  A 2,A2 

T  |  Ai  h  c{v/a}  :  Ai  ::  A?  H  A2 

Thus,  we  conclude. 


(5) 

by  induction  hypothesis  with  (1)  and  (3). 

(6) 

by  (t:Function)  with  (5). 

(7) 

by  (vs:4)  on  (6)  and  (4). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Cap-Elim)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:Cap-Elim)  with  (4). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Cap-Stack)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:Cap-Stack)  on  (4). 
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Case  (t: Cap-Unstack)  -  We  have: 


T  |  A0  h  v  :  A0  H  Ai 

(1) 

T  |  Aj, a  :  A0  e  :  A\  H  A2,  A? 

(2) 

T  |  Ai,  x  :  Ao  1-  e  :  A2  ::A2hA2 

by  hypothesis. 

(3) 

T  |  A]  h  c{v/a}  :  A[  ::  A?  H  A2 

by  inversion  (t:Cap-Unstack)  with  (2). 

(4) 

T  |  A]  h  e{vlx\  :  A!  H  A 2,A2 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

Thus,  we  conclude. 

by  (t:Cap-Unstack)  with  (4). 

i  (t: Subsumption)  -  We  have: 

r  |  Ao  l-  v  :  Ao  H  Ai 

(1) 

T  |  Ai,  a  :  Aq\-  e  :  A\  H  A2 

(2) 

T  l-  A15jc  :  A0  <:  A',  a  :  A('} 

by  hypothesis. 

(3) 

T  Aj ,  x  :  A()  l-  c  :  A2  H  A2 

(4) 

r  h  A2 

(5) 

ThA'  <:  A2 

(6) 

r  h  A0  <:  A(', 

by  inversion  on  (t:  Sub  sumption)  on  (2). 

(7) 

T  |  A„  h  v  :  A'  H  A; 

by  (Subtyping  Inversion)  on  (3)  on  a. 

(8) 

T  |  A)  l-  c{v/a}  :  A2  h  A!, 

by  (t: Subsumption)  on  (1)  with  (7). 

(9) 

T  h  Aj  <:  A) 

by  induction  hypothesis  on  (4)  and  (8). 

(10) 

T  |  Ai  h  e{v!x\  :  Ai  h  A2 

by  (Subtyping  Inversion)  on  (3). 

(ID 

by  (t: Subsumption)  on  (9)  with  (10),  (5)  and  (6). 

Thus,  we  conclude. 


Case  (t:Frame)  -  We  have: 

T  |  A()  h  v  :  A0  H  A[  (1) 

T  |  (Aj,a  :  A0),  A3  1-  c  :  A]  H  A2,  A3  (2) 

by  hypothesis. 

T  |  Aj ,  a  :  A0  6  :  Aj  H  A2  (3) 

by  inversion  on  (t:Frame)  with  (2). 


Ill 


r  |  A]  I-  e{v/x}  :  Ai  h  A2 


(4) 

by  induction  hypothesis  with  (1)  and  (3). 
T  |  Ai,  A3  h  c{v/4  :  Ai  h  A2,  A3  (5) 

by  (t:Frame)  on  (4)  with  A3. 

Thus,  we  conclude. 

Case  (t:Tag)  -  We  have: 

T  |  A()  h  v  :  A0  H  A! 

T  |  Aj,  a  :  A0  h  tffvo  :  tftAj  H  A2 

r|Ai,x:A0hv0:Ai  h  A2 

T  |  A]  i-  v0{v/a}  :  A]  h  A2 

T  |  Ai  h  t#v0{v/x}  :  t#Ai  H  A2 

T  |  A]  h  (t#v0){v/;c}  :  t#A,  h  A2 

Thus,  we  conclude. 


Case  (t:Case)  -  We  have: 

T  |  A()  h  v  :  A0  H  Ai  (1) 

T  |  Ai, x  :  A0  i-  case  v0  of  t j#Xj  -»  ey-  end  :  A  h  A2  (2) 

by  hypothesis. 

T  |  A,,  a  :  A0  I-  v0  :  2;  t,-#Af  H  A'  (3) 

T  |  A',  Xj  :  A'  h  e,-  :  A  h  A2  (4) 

i  <  j  (5) 

by  inversion  (t:Case)  with  (2). 

We  have  that  either: 

(a)  a  e  fv(v0) 

A  £  A'  (1.1) 

by  (Free  Variables)  on  (3). 

A  £  Xj  (1.2) 

by  def.  of  substitution  up  to  rename  of  bounded  variables. 
T  |  A',  a i  :  A'  h  <?,-{v/a}  :  A  h  A2  (1.3) 

since  a  cannot  occur  in  c,  and  by  (1.1)  nor  in  Y  by  (3). 
r  |  Altx  :  A()  h  v0{v/a}  :  2,  t ,#A'  h  A'  (1.4) 

by  induction  hypothesis  on  (1)  and  (3). 
T  |  Ai  h  case  v0{v/a}  of  tj#xj  ej{v/x)  end  :  A  h  A2  (1.5) 


by  (t:Case)  on  (5),  (1.3)  and  (1.4). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  (t:Tag)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:Tag)  with  (4). 

(6) 

by  (vs:  12)  on  (5). 
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r  |  Ai  h  (case  v0  of  t j#xj  ->  ej  end){v/x} :  A  h  A2  (1.6) 

by  (vs:  13)  on  (1.6)  and  (1.2). 

Thus,  we  conclude. 

(b)  jc  £  fv(v0) 

(X  :  Ao)  e  A'  (2.1) 

by  v  i  f v(<?). 

v  t  Xj  (2.2) 

by  def.  of  substitution  up  to  rename  of  bounded  variables. 

T  |  A",  xi  :  a;  h  eAv/x)  :  A  h  A2  (2.3) 

by  induction  hypothesis  where  A"  is  same  as  A'  without  x. 
r  |  A,  h  v0 { v / x}  :  Zi  t i#A'  H  A"  (2.4) 

since  x  cannot  occur  in  e  by  x  £  fv(<?). 

T  |  Ai  h  case  v0{v/x}  of  t j#xj  —>  ej{v/x}  end  :  A  h  A2  (2.5) 

by  (t:Case)  on  (5),  (2.3)  and  (2.4). 

T  |  Ai  h  (case  v0  of  tj#xj  ->  end){v/4  :  A  h  A2  (2.6) 

by  (vs:13)  on  (2.1)  and  (2.5). 

Thus,  we  conclude. 

Case  (t:Let)  -  Analogous  to  previous  cases.  First,  we  consider  the  different  sub-cases  where 
v  may  or  not  appear.  If  v  appears  on  the  first  expression  we  just  apply  the  induction 
hypothesis  there.  Otherwise,  we  apply  the  induction  hypothesis  on  the  body  of  the  let. 
Finally,  we  use  the  substitution  definition  (vs:  14)  to  “push”  the  substitution  outside. 

Cases  (t:Alternative-Left),  (t:Intersection-Right),  (t:Forall-Loc-Val),  (t:Forall-Type- 
Val),  (t:TypeOpenBind),  (t:TypeOpenCap),  (t:LocOpenCap),  (t:LocOpenBind)  -  im¬ 
mediate  by  applying  the  induction  hypothesis  on  the  inversion  and  then  re-applying  the 
rule. 


Case  (t:Fork)  -  We  have: 

r  I  A0  h  V  :  A0  h  A! 

T  |  Ai,jc  :  Aq  h  fork  e  : ![]  H  • 

r  |  Ai, x  :  Ao  i-  e  : ![]  H  • 

T  |  A,  h  e{v/x)  :  ![]  H  • 

T  |  Aj  i-  fork  e{vlx)  : ![]  h  • 

T|  Ai  h  (fork  e){v!x)  :  ![]  h  • 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  (t:Fork)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 


by  (t:Fork)  with  (4). 

(6) 

by  (vs:  17)  on  (5). 
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Thus,  we  conclude. 


Case  (t: Lock- Rely),  (t:Unlock-Guarantee)  -  immediate  since  x  cannot  occur  in  “lock  v” 
nor  “unlock  v”  as  all  those  values  (v)  must  be  typed  without  linear  resources.  Thus,  in 
this  case  substitution  is  vacuously  true. 

□ 

2.  (Pure) 

Proof.  We  proceed  by  induction  on  the  typing  derivation  of  T,  x  :  A0  |  A0  h  e  :  A\  H 
Case  (t:Ref)  -  We  have: 


F,p  :  loc  |  •  h  v0  :  !A0  H  •  (1) 

L,p  :  loc,  x  :  A0\  ■  p  :  ref  p  H  •  (2) 

by  hypothesis. 

T,p  :  loc  |  •  h  p  :  ref  p  H  •  (3) 

by  .v  $  fv(p)  on  (2). 

T,p  :  loc  |  •  h  p{v/.v}  :  ref  pH-  (4) 


by  (vs:l)  on  (3)  using  x  and  v. 

Thus,  we  conclude. 


Case  (t:Pure)  -  We  have: 

T  |  •  h  v0  :  !A0  H  •  (1) 

T,  xo  :  Aq  |  •  i-  v\  :  !Ai  h  •  (2) 

by  hypothesis. 

T,  Ao  :  A0  |  •  h  vi  :  Aj  H  •  (3) 

by  inversion  on  (t:Pure)  with  (2). 
T  |  xq  :  !A0  l-  Vi  :  Aj  H  •  (4) 

by  (t:Pure-Elim)  on  (3)  with  a'0. 
T  |  •  h  vi{v0/.v0}  :  Ai  H  •  (5) 

by  (Substitution  Lemma  -  Linear)  with  (1)  and  (4). 
L  |  •  h  vi{v0/.v0}  :  !Ai  H  •  (6) 

by  (t:Pure)  on  (5). 

Thus,  we  conclude. 


Case  (t:Unit)  -  We  have: 

L  |  •  i-  vo  :  !A0  h  • 

L,  x  :  Aq  |  •  h  Vi  :  ![]  H  • 
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(1) 

(2) 

by  hypothesis. 


r  I  •  h  Vl{v0/4  : ![]  h  •  (3) 

substitution  on  a  cannot  change  the  type  since  []  is  always  valid  by  (t:Unit). 

(and  substitution  cannot  change  a  value  to  become  an  expression). 

Thus,  we  conclude. 


Case  (t:Pure-Read)  -  We  have: 

r  |  •  h  V  : !A0  h  •  (1) 

T,  xq  :  Ao  |  •  i-  x\  :  \A\  h  •  (2) 

by  hypothesis  (matching  environments  and  type  with  (t:Pure-Read)). 
We  have  that  either: 


(a)  x0  =  X\ 

Thhv:!An- 

T,  r  :  A  |  •  l-  x  :  !A  H  ■ 

T  |  •  h  a{v/a}  :  !A  H  ■ 

Thus,  we  conclude. 

(b)  Xq  ±  X\ 

T  |  •  h  Xi  :  !A[  H  • 

T  |  •  h  Xiiv/xo)  :  !Ai  H  • 

Thus,  we  conclude. 

Case  (t: Linear- Read)  -  We  have: 

T  |  •  h  v  :  !A0  H  • 

T,  Ao  :  Aq  |  X\  :  A\  \-  x\  :  A\  h  • 

Ao  ^  X\ 

T  |  Ai  :  A\  h  ai{v/ao)  :  A{  H  • 
Thus,  we  conclude. 


(1.1) 

(1.2) 

by  restated  hypothesis  with  a  =  a0  =  x\ . 

and  with  A  =  A0  =  A  i . 

(1.3) 

by  (vs:2)  on  (1.1)  using  a  and  v. 


(2.1) 

by  a0  i  £v(ai)  on  (2). 

(2.2) 

by  (vs:3)  on  (2.1)  using  a0  and  v. 


(1) 

(2) 

by  hypothesis. 

(3) 

since  T  and  A  identifiers  cannot  collide. 

(4) 

by  (vs:3)  on  (2)  using  aq  and  v. 


Case  (t:Pure-Elim)  -  We  have: 

T  |  •  h  v  : !A0  H  •  (1) 

T,  Ao  :  Ao  |  Ao,  Ai  :  IA2  l-  e  :  Aj  H  Ai  (2) 

by  hypothesis. 

T,  Aq  :  Aq,  Ai  :  A2  |  A0  t-  e  :  A\  H  Ai  (3) 


115 


r,  Xi  :  A 2  |  A0  h  e{v/x 0}  :  Al  H  Ai 


by  inversion  on  (t:Pure-Elim)  with  (2) 

(4) 

by  induction  hypothesis  on  (1)  with  (3). 
T  |  Ao,  jci  :  !A2  I-  e{v/x o)  :  A\  H  Ai  (5) 

by  (t:Pure-Elim)  on  (4). 

Thus,  we  conclude. 

Case  (t:New)  -  We  have: 

T  |  •  h  v  :  !A„  H  •  (1) 

T,  x  :  A0  |  A0  h  new  v0  :  3/.(!ref  / rw  /  AO  H  Ai  (2) 

by  hypothesis. 

r,  x  :  Ao  |  Ao  I-  Vo  :  Ai  H  Ai  (3) 

by  inversion  on  (t:New)  with  (2). 
T  |  Aq  l-  v0{v/jc}  :  Ai  H  Ai  (4) 

by  induction  hypothesis  with  (3)  and  (1). 
T  |  Ao  h  new  v0{v/.v}  :  3/.(!ref  l ::  rw  /  Ai)  h  Ai  (5) 

by  (t:New)  with  (4). 

T  |  A0  h  (new  vq){v/x\  :  3/.(!ref  l ::  rw  l  A{)  H  Ai  (6) 

by  (vs:8)  on  (5). 

Thus,  we  conclude. 

Case  (t: Delete)  -  We  have: 

T  |  •  h  v  : !A0  H  •  (1) 

T,  x  :  Ao  |  Ao  I-  delete  vo  :  3/.Ai  h  Ai  (2) 

by  hypothesis. 

T,  x  :  Ao  |  A0  l-  vo  :  3/.(!ref  l ::  rw  /  Ai)  H  Ai  (3) 

by  inversion  on  (t:Delete)  with  (2). 
T  |  A0  l-  vq{v/x}  :  3/.(!ref  l ::  rw  /  Ai)  H  Ai  (4) 

by  induction  hypothesis  with  (3)  and  (1). 
T  |  A0  i-  delete  v0{v/.v}  :  3/.Ai  h  Ai  (5) 

by  (t:  Delete)  with  (4). 

T  |  A0  i-  (delete  v0){v/.v}  :  3/.Ai  h  Ai  (6) 

by  (vs:9)  on  (5). 

Thus,  we  conclude. 

Case  (t:Assign)  -  We  have: 

T  |  •  h  v  : !A0  h  •  (1) 

T,  x:A0\  A0  h  v0  :=  Vi  :  Aj  H  A2,  rw  p  A2  (2) 

by  hypothesis. 

T,  x  :  Aq  |  Ao  l-  vi  :  A2  H  A[  (3) 
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T,  ^  :  A0  |  Aj  h  v0  :  ref  p  H  A2,  rw  p  A] 
r  |  A0  h  Vi  {v/4  :  A2  h  Ai 
T  |  A]  h  v0{v/x}  :  ref  p  H  A2,  rw  p  A! 
r  |  A0  h  v0{v/4  :=  Vi{v/.t}  :  A!  H  A2,  rw  p  A2 
r  I  A0  h  (v0  :=  Vi ){v/4  :  Aj  h  A2,  rw  p  A2 
Thus,  we  conclude. 


(4) 

by  inversion  on  (t: Assign)  with  (2). 

(5) 

by  induction  hypothesis  on  (3)  with  (1). 

(6) 

by  induction  hypothesis  on  (4)  with  (1). 

(7) 

by  (t:Assign)  with  (5)  and  (6). 

(8) 

by  (vs:  11)  on  (7). 


Case  (t: Dereference-Linear)  -  We  have: 

T  |  •  h  v  :  !A„  H  •  (1) 

Y,x  :  A0  |  A0  h  !v0  :  A)  H  Ai,rw  p  ![]  (2) 

by  hypothesis. 

T,  v  :  A0  |  A0  i-  v0  :  ref  p  h  Ai,  rw  p  A\  (3) 

by  inversion  on  (t: Dereference- Linear)  with  (2). 
T  |  A()  h  v0{v/4  :  ref  p  H  Aj,  rw  p  A]  (4) 

by  induction  hypothesis  on  (3)  with  (1). 
T  |  A0  h  \v0{v/x}  :  Aj  H  A1?rw  p  ![]  (5) 

by  (t:  Dereference- Linear)  with  (4). 
r  |  A0  h  (!vo){v/4  :  Ai  H  Ai,rw  p  ![]  (6) 

by  (vs:  10)  on  (5). 

Thus,  we  conclude. 


Case  (t: Dereference-Pure)  -  Analogous  to  (t:Dereference-Linear). 
Case  (t:Record)  -  We  have: 


T  |  •  i -v:!A'h- 

T, x  :  A'  |  A  h  {f  =  v'}  :  [f  :  A]  h  • 


T,x:  A'  |  Ah  v;  :  A,  H  • 


T  |  A  h  v'{v/xj  :  Af  H  ■ 


T|  Ah  {f  =  v'{v/jc}}  :  [f  :  A]  h  • 


T  |  A  h  ({ f  =  v'}){v/x}  :  [f  :  A]  h  • 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Record)  with  (2). 

(4) 

by  induction  hypothesis  on  (3)  with  (1). 

(5) 

by  (t:Record)  on  (4). 

(6) 

by  (vs:5)  on  (5). 
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Thus,  we  conclude. 


Case  (t: Selection)  -  We  have: 

T|-hv:L4'H- 

T,  x  :  A'  |  A0  l-  Vo-f  :  A  H  A| 

F,x:A'  |  A0  h  vo  :  [f  :  A]  H  Ai 

T  |  A0  h  v0{v/ x}  :  [f  :  A]  H  Aj 

T  |  A0  l-  V(){v/v}.f  :  A  H  A| 

r  |  A()  h  (v0.f){v/x}  :  A  H  Ai 

Thus,  we  conclude. 

Case  (t: Application)  -  We  have: 

T  |  •  h  v  :  !A'  h  • 

T,  x  :  A!  |  Ao  h  vo  vj  :  Aj  H  A2 

T,  x  :  A'  |  Ao  1-  vo  :  Ao  A\  H  Ai 
T,  x  :  A'  |  Aj  1-  vi  :  A0  H  A2 

T  |  Ao  l-  v0{v/x}  :  Ao  Ai  h  Ai 

T  |  Aj  h  vi{v/x}  :  A0  H  A2 

T  |  A0  h  v0{v/x}  vi{v/x}  :  Ai  H  A2 

T  |  A0  h  (v0  vi){v/x}  :  Ai  H  A? 

Thus,  we  conclude. 

Case  (t:Function)  -  We  have: 

T  |  •  h  v  :  !A'  h  • 

T,  Xg  :  A'  |  A  h  Ax\.c  :  Aq  — 0  A[  h  • 
T,  xo  :  A'  |  A,  x\  :  A0  1-  e  :  Ai  H  • 
x0  ^  Xi 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Selection)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t: Selection)  with  (4). 

(6) 

by  (vs:6)  on  (5). 


(1) 

(2) 

by  hypothesis. 

(3) 

(4) 

by  inversion  on  (t: Application)  with  (2). 

(5) 

by  induction  hypothesis  with  (1)  on  (3). 

(6) 

by  induction  hypothesis  with  (1)  on  (4). 

(7) 

by  (t: Application)  with  (5)  and  (6). 

(8) 

by  (vs:7)  on  (7). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Function)  with  (2). 

(4) 
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by  def.  of  substitution  up  to  rename  of  bounded  variables. 
T  |  A,  xi  :  A0  e{v/x0}  :  Ai  H  •  (5) 

by  induction  hypothesis  with  (3)  and  (1). 
T  |  A  l-  Ax\.e{vlxo}  \  Aq  -o  A\  -\  ■  (6) 

by  (t:Function)  with  (6). 

r  |  A  h  (Ax\.e){v / xq)  :  A0  -o  Aj  h  •  (7) 

by  (vs:4)  on  (6)  and  (4). 

Thus,  we  conclude. 

Case  (t:Cap-Elim)  -  We  have: 

T  |  •  h  v  :  !A'  H  •  (1) 

T,  x  :  A!  |  A0,  xq  :  Ao  ::  A  2  I-  c  :  Aj  H  Aj  (2) 

by  hypothesis. 

T,  x  :  A'  |  A0,  xq  :  Aq,A2  I-  c  :  Aj  H  Aj  (3) 

by  inversion  on  (t:Cap-Elim)  with  (2). 
r  |  Ao,ao  :  Ao,A2  I-  e{v/x}  :  A\  H  Ai  (4) 

by  induction  hypothesis  with  (1)  and  (3). 
r  |  Ao,ao  :  Ao  ::  A2  I-  e{vlx)  :  A]  H  A|  (5) 

by  (t:Cap-Elim)  with  (4). 

Thus,  we  conclude. 

Case  (t:  Cap-Stack)  -  We  have: 

T  |  •  1-  v  :  !A'  H  •  (1) 

T,  x  :  A!  |  A0  h  e  :  Ao  ::  Aj  h  A[  (2) 

by  hypothesis. 

T, x  :  A?  |  Ao  h  e  :  Ao  H  A|,Aj  (3) 

by  inversion  on  (t:Cap-Stack)  with  (2). 
r  |  A0  h  e{\>lx}  :  A0  h  Ai,Aj  (4) 

by  induction  hypothesis  with  (1)  and  (3). 
T  |  A0  h  <?{v/4  :  A0  ::  Ai  H  Ai  (5) 

by  (t:Cap-Stack)  with  (4). 

Thus,  we  conclude. 

Case  (t: Cap-Unstack)  -  We  have: 

T  |  •  1-  v  :  !A'  H  •  (1) 

T,  x  :  A'  |  Ao  h  6  :  Ao  H  Aj,Aj  (2) 

by  hypothesis. 

T,  x  :  A'  |  Ao  h  s  :  Ao  ::  Aj  H  A[  (3) 

by  inversion  on  (t:Cap-Unstack)  with  (2). 
T  |  A0  h  e{v/x }  :  A0  ::  Ai  H  Ai  (4) 
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r  |  Ao  h  e{vlx\  :  Ao  H  Aj,Ai 
Thus,  we  conclude. 

Case  (t:Frame)  -  We  have: 

T  |  •  h  v:!A'h- 

I\x:  A'  |  A0,  A2  h  e  :  A  h  A[,  A2 
T,  x  :  A'  |  A0  l-  e  :  A  h  A| 

T  |  Ao  h  e{v/x}  :  A  H  A| 
r  |  A(),  A2  I-  e{v I x)  :  A  H  Ai,  A2 
Thus,  we  conclude. 

Case  (t: Subsumption)  -  We  have: 

T  |  •  h  v:!A'h- 

T,  x  :  A'  |  Ao  1-  e  :  A]  h  Aj 

T  l-  A()  <:  Aq 

T,  x  :  A'  |  A'0  h  e  :  A0  H  A' 
r  h  Ao  Ai 

r  h  a;  c  Ai 

r  |  A',  h  e{v / x}  :  A0  H  A' 

T  |  Aq  h  fjv/x}  :  A[  H  A] 

Thus,  we  conclude. 

Case  (t:Tag)  -  We  have: 

T  |  •  h  v  :  !A'  H  • 

T,  x  :  A'  |  Aq  h  t#vo  :  tttAj  H  A[ 
T,  x  :  A'  |  A0  i-  Vo  :  Aj  h  Ai 
T  I  Aq  h  Vq{v/x}  :  A]  H  Ai 


by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:Cap-Unstack)  with  (4). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  on  (t:Frame)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 

(5) 

by  (t:Frame)  with  A2. 


(1) 

(2) 

by  hypothesis. 

(3) 

(4) 

(5) 

(6) 

by  inversion  on  (t:Subsumption)  with  (2). 

(7) 

by  induction  hypothesis  with  (1)  and  (4). 

(8) 

by  (t: Subsumption)  with  (7),  (3),  (5)  and  (6). 


(1) 

(2) 

by  hypothesis. 

(3) 

by  inversion  (t:Tag)  with  (2). 

(4) 

by  induction  hypothesis  with  (1)  and  (3). 
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r  |  A0  h  t#v0{v/x}  :  t#A j  h  Ai 


(5) 

by  (t:Tag)  with  (4). 

r  |  A0  h  (t#v0){v/4  :  t#Ai  H  Ai  (6) 

by  (vs:  12)  on  (5). 

Thus,  we  conclude. 


Case  (t:Case)  -  We  have: 

T  |  •  i-  v  :  !A'  H  •  (1) 

T,  a  :  A'  |  A0  h  case  v0  of  t 7#a7  —>  <?7  end  :  A  h  A,  (2) 

by  hypothesis. 

C^A'IA,  h  v0  :  Yji  t/#A.  H  A'  (3) 

T,  a  :  A'  |  A',  a,-  :  A'  h  £>, :  A  h  A2  (4) 

i  <  j  (5) 

by  inversion  (t:Case)  with  (2). 
a  ±  A  j  (6) 

by  def.  of  substitution  up  to  rename  of  bounded  variables. 
T  I  A,  h  v„{v/a}  :  2,  t (#A;  h  A'  (7) 

by  induction  hypothesis  on  (3)  and  (1). 
T  |  A',  A/  :  A'  h  C/{v/a}  :  A  h  A2  (8) 

by  induction  hypothesis  on  (4)  and  (1). 
T  |  A,  h  case  v0{v/a}  of  tj#xj  ->  eyjv/.v}  end  :  A  h  A2  (9) 

by  (t:Case)  on  (5),  (7)  and  (8). 
T  |  Ai  h  (case  v0  of  t j#xj  ->  e7-  end){v/A}  :  A  h  A2  (10) 

by  (vs:  13)  on  (9)  and  (6). 

Thus,  we  conclude. 


Case  (t:Alternative-Left),  (t:Intersection-Right)  -  Immediate  by  applying  the  induction 
hypothesis  on  the  inversion  and  then  re-applying  the  rule. 

Case  (t:Let)  -  We  have: 

T  |  •  h  v  :  !A'  H  •  (1) 

T,  a  :  A'  |  A0  h  let  Ai  =  e0  in  e\  end  :  Ai  h  A!  (2) 

by  hypothesis. 

T,  a  :  A!  |  A0  i-  Co  :  Aq  h  A2  (3) 

T,  a  :  A '  |  At,  a2  :  Aq  l-  <?i  :  Aj  H  A[  (4) 

by  inversion  on  (t:Let)  with  (2). 
A0  ±  Ai  (5) 

by  def.  of  substitution  up  to  rename  of  bounded  variables. 
T  |  A0  h  e0 {v/xj  :  A0  H  A2  (6) 

by  induction  hypothesis  on  (3)  and  (1). 
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r  |  A2,  xx  :  Aq  I-  e\ {v/a}  :  Ax  H  Aj 


(7) 

by  induction  hypothesis  on  (4)  and  (1). 
T  |  A0  h  let  xi  =  e0 {v/a}  in  ex {v/a}  end  :  Ai  h  Ai  (8) 

by  (t:Let)  with  (6)  and  (7). 

T  |  A0  h  (let  x\  =  <?0  in  ex  end){v/4  :  Ax  h  A}  (9) 

by  (vs:  14)  on  (8)  and  (5). 

Thus,  we  conclude. 

Cases  (t: Alternative-Left),  (t:Intersection- Right),  (t:Forall-Type-Val),  (t:Forall-Loc- 
Val),  (t:TypeOpenBind),  (t:TypeOpenCap),  (t:LocOpenCap),  (t:LocOpenBind)  -  are 
immediate  by  applying  the  induction  hypothesis  on  the  inversion  and  then  re-applying 
the  rule. 

Case  (t:Fork)  -  We  have: 

T  |  •  h  v  :  !A'  H  •  (1) 

T,  a  :  A'  |  Aj  I-  fork  c  :  ![]  h  •  (2) 

by  hypothesis. 

F,x:  A'  |  Ax  h  e  : ![]  h  •  (3) 

by  inversion  (t:Fork)  with  (2). 
T  |  A,  I-  e{v/x\  :![]-)•  (4) 

by  induction  hypothesis  with  (1)  and  (3). 
T  |  Aj  i-  fork  e{v/ x]  : ![]  -i  •  (5) 

by  (t:Fork)  with  (4). 

r  |  Aj  h  (fork  e){v/jc} : ![]  h  •  (6) 

by  (vs:  17)  on  (5). 

Thus,  we  conclude. 

Case  (t: Lock- Rely)  -  We  have: 

T  |  •  h  v  :  !A'  h  •  (1) 

T, a  :  A'  |  A, A0  Ai  h  lock)/  : ![]  h  A,A0,Ai  (2) 

by  hypothesis. 

T,  a  :  A'  |  •  h  v'  :  ref  p  H  •  (3) 

P  6  A0  (4) 

by  inversion  (t:Lock-Rely)  with  (2). 
r|-bv'{v/A}:![]H-  (5) 

by  induction  hypothesis  with  (1)  and  (3). 
r  I  A,  A()  =>  Aj  h  lock  7{v/a}  :  ![]  h  A,  A0,  A,  (6) 

by  (t:Lock-Rely)  with  (4)  and  (5). 
r  I  A,  A()  =>  Ax  h  (lock7){v/A)  : ![]  H  A,A0,Ai  (7) 

by  (vs:  15)  on  (6). 
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Thus,  we  conclude. 


Case  (t: Unlock-Guarantee)  -  We  have: 


T  |  •  b  v:!A'h- 

Y,x  :  A'  |  A,A0,Ao;A!  b  unlock  V  : ![]  h  A,  A] 


(1) 
(2) 

by  hypothesis. 

(3) 

(4) 

by  inversion  (t: Unlock- Guarantee)  with  (2). 

(5) 

by  induction  hypothesis  with  (1)  and  (3). 
T  |  A,  A0,A0;  Al  b  unlock  V{v/x)  :  ![]  h  A,  A!  (6) 

by  (t:Lock-Rely)  with  (4)  and  (5). 
T  |  A,A0,A0;  Aj  b  (unlock  7){v/4  :  ![]  H  A,  A!  (7) 

by  (vs:  16)  on  (6). 

Thus,  we  conclude. 


T,  x  :  A'  |  •  b  v'  :  ref  p  h 
P  6  A0 

T  |  •  b  v'{v/.v}  :  ![]  h  • 


□ 

3.  (Location  Variable)  -  immediate  by  (Well-Formed  Type  Substitution)  since  our  expressions 
do  not  contain  types. 


4.  (Type  Variable)  -  analogous  to  (Location  Variable). 


□ 
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H.7  Values  Lemma 

Lemma  20  (Values  Lemma).  If  v  is  a  closed  value  such  that 


T  |  A  h  v  :  A  h  A' 

then 

Tt  Ac  Av,  A'  T  |  Av  h  v  :  A  H  • 
Proof.  By  induction  on  the  typing  derivation  of  T  |  A  h  v  :  A  h  A'. 


Case  (t:Ref)  -  We  have: 

T,p  :  loc  |  •  h  p  :  ref  p  H  •  (1) 

by  hypothesis. 

Thus,  by  making: 

Av  =  •  (2) 

A'  =  •  (3) 

We  immediately  conclude. 

Case  (t:Pure)  -  We  have: 

T  |  •  h  v  :  !A  h  •  (1) 

by  hypothesis. 

Thus,  by  making: 

Av  =  •  (2) 

A'  =  •  (3) 

We  immediately  conclude. 

Case  (t:Unit)  -  We  have: 

Tl-i-v  :![]-)•  (1) 

by  hypothesis. 

Thus,  by  making: 

Av  =  •  (2) 

A'  =  •  (3) 

We  immediately  conclude. 


Case  (t:Pure-Read),  (t:Linear-Read)  -  value  not  closed. 

Case  (t:Pure-Elim)  -  Environment  not  closed. 

Case  (t:New),(t:Delete),  (t:  Assign),  (t:Dereference-Linear),  (t:Dereference-Pure)  -  Not  a  value. 


124 


Case  (t:Record)  -  We  have: 


r|A0h{f  =  v}:[f  :A]HAi  (1) 

by  hypothesis. 

r  |  A0  h  v  :  A  h  A[  (2) 

by  inversion  on  (t:Record)  with  (1). 
r  i-  A0  <:  Av,  Aj  (3) 

r  |  Av  h  v  :  A  h  •  (4) 

by  induction  hypothesis  on  (2). 

r  |  Av  h  {f^T}  :  [FT A]  H  •  (5) 

by  (t:  Record)  on  (4). 

Therefore,  by  (3)  and  (5)  we  conclude. 

Case  (t:Selection),  (t: Application)  -  Not  a  value. 

Case  (t:Function)  -  We  have: 

T  |  A  h  Ax.e  :  A0  — o  A  i  H  •  (1) 

by  hypothesis. 

Thus,  by  making: 

A'  =  •  (2) 

We  immediately  conclude. 

Case  (t:Cap-Elim)  -  Environment  not  closed. 


Case  (t: Cap-Stack)  -  We  have: 


r  |  Ao  i-  v  :  Ao  ::  Aj  H  Aj  (1) 

by  hypothesis. 

T  |  Ao  l-  v  :  Ao  h  Ai,Ai  (2) 

by  inversion  on  (t:Cap-Stack)  with  (1). 
T  l-  A0  <:  Av,Ai,A!  (3) 

r  |  Av  h  v  :  Ao  h  •  (4) 

by  induction  hypothesis  on  (2). 
T  |  Av,  Ai  l-  v  :  Ao  H  A\  (5) 

by  (t:Frame)  on  (4)  using  A\. 

T  |  Av,  A  ]  i-  v  :  A0  ::  A\  H  •  (6) 

by  (t:Cap-Stack)  on  (5). 


Therefore,  by  (3)  and  (6)  we  conclude. 
Case  (t: Cap-Unstack)  -  We  have: 
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r  |  Ao  h  v  :  Aq  h  Ai,Ai  (1) 

by  hypothesis. 

r  |  Ao  i-  v  :  Aq  ::  A\  h  Aj  (2) 

by  inversion  on  (t:Cap-Unstack)  with  (1). 
r  i-  A0  <:  Av,  A!  (3) 

r  |  Av  l-  v  :  Aq  ::  A i  H  •  (4) 

by  induction  hypothesis  on  (2). 
r  |  Av.  h  v  :  A0  H  A]  (5) 

by  (t:Cap-Unstack)  with  (4). 

r  h  Av  <:  A'v,Ai  (6) 

r  |  a;,  h  V  :  Ao  h  •  (7) 

by  induction  hypothesis  on  (5). 
rh  A()<:  A;,Aj,A!  (8) 


by  transitivity  of  subtyping  with  (3)  and  (6). 

Therefore,  by  (7)  and  (8)  we  conclude. 

Case  (t:Frame)  -  We  have: 


r  |  Ao,  A2  1-  v  :  A  H  Ai,  A2 
T  |  Aq  l-  v  :  A  h  Ai 


r  1-  A0  <:  Av,  Ai 
T  |  A,,  h  v  :  A  h  • 


T  l-  Aq,  A2  <:  Av,  Aj ,  A2 


(1) 

by  hypothesis. 

(2) 

by  inversion  on  (t:Frame)  with  (1). 

(3) 

(4) 

by  induction  hypothesis  on  (2). 

(5) 

by  (1)  and  (3)  we  know  we  can  add  A2. 


Therefore,  by  (4)  and  (5)  we  immediately  conclude. 
Case  (t: Subsumption)  -  We  have: 


T  |  A(>  h  v  :  Aj  H  Aj  (1) 

by  hypothesis. 

T  h  A„  <:  A[,  (2) 

T  |  A;,  h  v  :  A()  H  A;  (3) 

T  h  Ao  <:  A!  (4) 

T  h  A;  <:  A!  (5) 

by  inversion  on  (t: Subsumption)  with  (1). 

ThA;<:Av,A;  (6) 

r  |  Av  h  V  :  Ao  h  •  (7) 

by  induction  hypothesis  on  (3). 

T  hA'<:Av,A!  (8) 


by  transitivity  of  subtyping  with  (5)  and  (6). 
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r  l-  A0  <:  Av,  Ai 


(9) 

by  transitivity  of  subtyping  with  (2)  and  (8). 
r  |  Av  h  v  :  Ai  H  •  (10) 

by  (t: Subsumption)  with  (sd:Symmetry)  and  (4)  on  (7). 
Therefore,  by  (9)  and  (10)  we  conclude. 

Case  (t:Tag)  -  We  have: 


T  I  A0  h  t#v  :  t#A  H  •  (1) 

by  hypothesis. 

T  |  A0  h  v  :  A  h  •  (2) 

by  inversion  on  (t:Tag)  with  (1). 
T  i-  Ao  <:  Av,  Ai  (3) 

T  |  Av  h  v  :  A  h  •  (4) 

by  induction  hypothesis  on  (2). 
T  |  Av  h  t#v  :  t#A  h  •  (5) 

by  (t:Tag)  on  (4). 


Therefore,  by  (5)  and  (3)  we  conclude. 
Case  (t:Case)  -  Not  a  value. 

Case  (t:Alternative-Left)  -  We  have: 


T  |  A0,  A0  ©  A[  I-  v  :  A2  H  Ai  (1) 

by  hypothesis. 

r  |  A(),  Ao  h  v  :  Ai  H  Ai  (2) 

r  |  A0,Ai  h  v  :  A2  H  Aj  (3) 

by  inversion  on  (t: Alternative-Left)  with  (1). 

T  l-  A0,A0  <:  Av,  Aj  (4) 

T  |  Av  l-  v  :  A2  H  •  (5) 

by  induction  hypothesis  on  (2). 

T  1-  Ao,Ai  <:  Av,  Aj  (6) 

T  |  Av  h  v  :  A2  -1  •  (7) 

by  induction  hypothesis  on  (3). 

T  h  Ao,  A0  ©  Ai  <:  Av,  Ai  (8) 

by  (sd:Alternative-L)  on  (4)  and  (6). 


Therefore,  by  (8)  and  (7)  we  conclude. 
Case  (t:Intersection-Right)  -  We  have: 

T  |  A0  h  v  :  Aq  h  Ai,  Ai&A2 
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(1) 

by  hypothesis. 


r  |  A0  h  v  :  A0  H  Ai,Ai  (2) 

r  |  Ao  i-  v  :  Ao  H  Ai,A2  (3) 

by  inversion  on  (t: Intersection- Right)  with  (1). 
r  l-  Ao  <:  Av,Ai,Ai  (4) 

r  |  Av  h  v  :  A0  H  •  (5) 

by  induction  hypothesis  on  (2). 
r  i-  A0  <:  Av,  Aj,  A2  (6) 

r  |  Av  h  v  :  Ao  h  •  (7) 

by  induction  hypothesis  on  (3). 
r  l-  Ao  <:  Av,  A1?  A!&A2  (8) 

by  (sd:Intersection-R)  on  (4)  and  (6). 


Thus,  by  (8)  and  (7)  we  conclude. 

Case  (t:Let),  (t:Fork),  (t:Lock-Rely),  (t: Unlock-Guarantee)  -  Not  values. 

Case  (t:Forall-Loc-Val),  (t:Forall-Type-Val)  -  Immediate  since  both  rules  have  no  resulting 
effects. 

Case  (t:TypeOpenBind),  (t:TypeOpenCap),  (t:LocOpenCap),  (t:LocOpenBind)  -  Environment  not 
closed. 

□ 
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H.8  Protocol  Lemmas 

Lemma  21  (Composition  Progress).  If  T  h  R  ^  P  ||  Q  then  <  T  h  ^  .P  ||  ^  )  ' — >  C. 

In  other  words,  if  two  protocols  compose  safely,  then  the  configuration  can  always  take  a  step 
to  some  other  set  of  configurations. 

Proof.  By  induction  on  the  derivation  of  Y  h  R  ^  P  ||  Q\ 


Y^R^PWQ  (1) 

by  hypothesis. 

(Y\-R^  P\\  Q>T  (2) 

by  inversion  on  (1)  with  (wf:Split). 
(Y^R^P\\Q)^C  (3) 

CT  (4) 


by  inversion  on  (2)  with  (wf:Configuration). 

Thus,  we  conclude  by  (3). 

□ 


Lemma  22  (Composition  Preservation).  If  T  h  R  P  ||  Q  and 
<  T  h  R  ^  P  ||  Q  )  i-»  <  P  h  R'  ^  P'  ||  Q  >  •  C  then  P  h  R’  =»  P'  ||  Q . 


If  two  protocols  compose  safely  then  the  respective  configuration  can  take  a  step  by  (Compo¬ 
sition  Progress).  We  now  show  that  the  resulting  configuration  still  composes  safely.  Thus,  all 
interference  produced  by  a  protocol  is  expected  by  all  other  protocols  of  that  state,  regardless  of 
how  they  are  interleaved  or  how  many  times  the  protocol  is  split.  In  other  words,  the  protocols 
never  get  stuck  as  their  rely  assumptions  are  valid. 


Proof.  Immediate  by  (wf:Configuration)  and  then  (wf:Split)  on  each  new  configuration.  That  is, 
since  we  know  the  configurations  compose  to  begin  with,  then  by  the  definition  of  (wf:Configuration) 
they  will  conform  to  all  possible  future  reachable  configurations. 

By  induction  on  the  derivation  of  T  h  R  ^  P  ||  Q\ 


Y^R^P\\Q 

<  T  h  R  ^  P  ||  Q)  <  F  h  R' 

<  T  h  R  ^  P  ||  Q  )  <  P  h  R' 

<P  h  R'  ^  P’  ||  Q  )  ■  C| 

<P  vR'  ^  F  ||  Q  >T 

T'hii'^  F  ||  Q’ 


Thus,  we  conclude  by  (7). 


(1) 

P'  II  Q!  )  ■  C  (2) 

by  hypothesis. 

(3) 

by  inversion  on  (1)  with  (wf:Split). 
P'  II  Q!  )  ■  C  (4) 

(5) 

by  inversion  on  (2)  with  (wf:Configuration). 

(6) 

by  (wf:Configuration)  and  (cf:AllStep)  on  (5). 

(7) 

by  (wf:  Split)  on  (6). 
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□ 


Lemma  23  (Protocol  Properties).  Protocol  Composition  obeys  the  follow  properties: 

T  i-  R  R  ||  none  (Identity) 

If  T  h  R  ^  P0  II  Pi  then  T  l-  R  ^  Pi  ||  P0  (Commutativity) 

If  T  h  R  ^  P0  II  (Pi  II  Pi)  then  Y  b  R  ^  (P0  II  Pi)  II  Pi  (Associativity) 

Showing  identity  and  that  protocol  composition  is  commutative  are  immediate.  We  now  show  that 
protocol  composition  is  associative. 

Lemma  24  (Associativity).  If  we  have: 

r  h  R  ^  P  ||  Q  Y  h  P  =>  Po  ||  Pi 

then,  exists  W  such  that: 

T  h  R  ^  PQ  ||  VP  r  h  W  =>  P{  ||  Q 

( i.e.  if  r  h  R  ^  (P^hPO  II  Q  then  Y  h  R  ^  P0  ||  (P^0 ). 

p  w 

Proof.  We  proceed  by  induction  on  the  structure  of  S .  Note  that  we  omit  cases  related  to  the  use 
of  (cf-rs:Subsumption)  and  (cf-rs:Weakening)  since  they  are  straightforward  and  detract  from  the 
core  aspects  of  the  proof. 


1.  Case  R  =  none.  Immediate  since  neither  protocol  can  take  a  step. 

2.  Case  R  =  R0  ©  Pi ,  we  have: 


r  l-  R( )  ©  R\  ^  P  ||  Q 
Y  h  P  ^  Po  ||  P, 

r  h  Ro  ^  P II  Q 
Y^R^PWQ 


(1) 

(2) 

by  hypothesis. 

(3) 

(4) 

by  inversion  with  (cf-rs:StateAlternative)  on  (1). 


Then,  by  induction  hypothesis  we  have  that  exists  W  such  that  (remember  that  we  can 
weaken  W  to  match  both  application  of  the  induction  hypothesis,  for  instance  by  applying 
subtyping  rules): 


Th«„^  Po  ||  W 

(5) 

Th  W^P{  \\Q 

(6) 

T  h  P,  ^  P0  II  W 

(7) 

by  induction  hypothesis  on  (2)  and  (3),  and  (2)  and  (4). 

ThP0©Pi  ^  Po  II  W 

(8) 

by  (cf-rs:StateAlternative)  with  (5)  and  (7). 

Thus,  we  conclude. 
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3.  Case  R  =  R0&Ri,  we  have: 


r  h  P„&P,  =>  P\\Q  (1) 

r  h  P  ^  Po  II  P i  (2) 

by  hypothesis. 

r  h  R0  ^  P  II  Q  (3) 

by  inversion  with  (cf-rs:StateIntersection)  on  (1). 
Then,  by  induction  hypothesis  we  have  that  exists  W  such  that: 

T  b  R0  ^  P0  II  W  (4) 

r  h  w  ^  Px  ||  Q  (5) 

by  induction  hypothesis  with  (2)  and  (3). 
T  h  R0&Rl  ^  P0  ||  W  (6) 

by  (cf-rs:State!ntersection)  on  (4). 


Thus,  we  conclude. 


4.  Case  R  =  S  (a  non-protocol  type),  we  have: 


(1) 

(2) 

by  hypothesis. 


ThS  ^  P\\Q 
T  h  P  ^  Po  ||  Pi 


We  now  do  a  case  analysis  on  the  structure  of  P.  We  omit  cases  where  P  =  none,  P  = 
P'  ©  P",  and  P  =  P'&P'  since  they  are  straightforward  and  instead  focus  on  actual  protocol 
steps  of  P. 


(a)  Case  P  =  A  =>  A';  P',  we  can  re-write  our  hypothesis: 


T  h  A  (A  =>  A';P')  ||  Q  (1) 

Th(A=*A';P')^Pol|Pi  (2) 

by  hypothesis. 

Then,  by  inversion  on  (2)  we  have  that: 

P„  =  A  =>  A';  P'0  (3) 

P1=A^A';p;  (4) 


by  inversion  on  (2)  with  (cf-ps:Step). 

Thus,  we  can  build  W  such  that  it  intertwines  both  Pi  and  Q  with  a  &.  Assume  that 
W'  is  such  a  protocol  but  built  for  the  next  step  of  the  protocol  and  where  Q  is  the 
intertwine  version  Q  so  that  it  obeys  the  intended  protocol  condition.  Then  we  can 
have: 

W  =  (A  =>  A';  W')&Q'  (5) 

Thus,  we  conclude  (noting  that  by  (3)  we  see  that  P0  also  steps  with  A). 
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(b)  Cases  P  =  A  =>  VI. P'  and  P  =  A  =>  VX  <:  A".P'  are  straightforward  by  inversion 
and  application  of  the  induction  hypothesis.  Similarly,  the  sub-case  where  P0  (or  Pi) 
transition  by  (cf-ps:TypeApp)  or  by  (cf-ps:LocApp)  do  not  affect  the  step  since  the  rely 
type  is  unchanged.  Furthermore,  we  can  build  W  with  the  applied  type/location  already 
there. 

(c)  Cases  P  =  3X  <:  A"  .P'  and  P  =  3/.P'  are  straightforward  by  inversion  on  (cf- 
ss:Open*)  and  (cf-ps:Exists*),  induction  hypothesis,  and  re-applying  the  rule. 

(d)  Case  P  =  S  (ownership  recovery),  we  have: 

t^s^swq  (i) 

r  h  s  ^  p()  ||  P!  (2) 

by  hypothesis. 

Then,  by  inversion  on  (2)  we  have  that  either: 

•  P0  or  Pi  are  also  S .  Then,  since  the  protocols  compose  safely,  the  other  protocol 
cannot  touch  the  shared  state  since  the  shared  state  becomes  none.  Therefore,  W 
is  simply  the  combination  of  Q  and  the  other  protocol  that  recovers  ownership. 

•  Po  or  Pi  extend  the  uses  of  S ,  i.e.  they  are  appending  some  protocol  to  what  was 
previously  ownership  recovery.  Thus,  we  have: 

P0  =  51  =>  S';P'0  (3) 

Pi  =  S  =>  S'’, P\  (4) 

by  inversion  on  (2)  with  (cf-ps:Step). 
But  since  Q  composes  with  5,  Q  cannot  use  the  shared  state  and  must  be  equiva¬ 
lent  of  none.  Therefore,  we  can  build  W  =  P\  and  immediately  conclude. 

5.  Case  R  =  A  =>  A';  P"  (a  protocol  type),  we  have: 


Th(A^A';P")^P||0  (1) 

T  h  P  ^  P0  ||  P,  (2) 

by  hypothesis. 

p  =  A^A';P'  (3) 

P0  =  A  =>  A';  Pq  (4) 

Pi  =  A  =>  A';  P(  (5) 


by  inversion  on  (2)  with  (cf-ps:Step). 

As  before,  we  can  build  W  by  intertwining  Q  and  Pi  with  the  W'  protocol  resulting  from 
applying  the  induction  hypothesis  to  the  next  step.  So  that,  as  done  above: 
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IT  =  (A  =>  A';  W')&Q' 
Thus,  we  conclude. 


(6) 


6.  Cases  R  =  31.R'  (case  R  =  3X  <:  A" .R’  is  analogous),  we  have: 


T  h  31.R'  ^  P  ||  Q  (1) 

r  h  p  =>  p0  II  Pi  (2) 

by  hypothesis. 

P  =  31.P'  (3) 

Po  =  3/.P'  (4) 

Pi  =  3/.P)  (5) 

Q  =  3 l.Q '  (6) 

since  the  protocols  compose  with  R  and  P. 
T,l :  loc  \-R'  ^  P'  ||  Q  (7) 

r,  / :  loc  h  P' ^  P' II  p;  (8) 

by  inversion  on  (2)  with  (cf-ps:ExistsLoc). 
Then,  by  induction  hypothesis  there  exists  a  IT  such  that: 

T,/ :  loc  \-R'  ^  P'0  ||  IT  (9) 

T,/ :  loc  h  IT  =>  P;  ||  Q'  (10) 

by  induction  hypothesis  on  (7)  and  (8). 

T  h  31.R'  ^  3l.P'Q  ||  3/.1T  (11) 

T  h  3/. IT  =>  3l.P\  ||  3 l.Q’  (12) 

by  (cf-ps:ExistsLoc)  on  (9)  and  (10). 

Thus,  we  conclude. 


7.  Case  R  =  A  =>  V/.P"  (case  P  =  5  =>  VX  <:  A" .R"  is  analogous),  we  have: 

T  h  A  =>  V/.P'  =*  P  ||  Q  (1) 

T  h  P  =>  P0  ||  P,  (2) 

by  hypothesis. 

We  have  that  P  will  either  “re-use”  the  V  or  do  a  type  application.  Either  case  is  straightfor¬ 
ward  by  inversion  and  induction  hypothesis. 


□ 
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H.9  Preservation 

Note  that  preservation  is  only  defined  over  closed  programs  and  expressions  so  that  they  can  step. 
Theorem  5  (Program  Preservation).  If  we  have 

To  |  Ao  l-  Ho  To  |  Ao  l-  To  Ho  ;  To  *—>  H\  ;  T\ 
then,  for  some  Aj  and  Ti,  we  have 


r0,ri  |  Ai  i-  Hi  r0,ri  |  a 5  T] 

Proof.  We  proceed  by  induction  on  the  typing  derivation  of  f0  |  A()  b  Tq. 


Case  (wf: Program)  -  we  have: 


r„  I  A()  h  Ho  (1) 

To  I  Ao  h  Tq  (2) 

Ho  ;  To  ^  Hr,  Ti  (3) 

by  hypothesis. 

r0  |  A0,  h  c,  :  ![]  h  •  (4) 

ie{0,...,n}  (5) 

77  >  0  (6) 

To  =  e0  •  ...  •  e„  (7) 

Ao  =  A0o, ...,  A0„  (8) 

by  inversion  on  (wf:Program)  with  (2)  noting  that  the  order  of  each  threads  in  T0  is  not  important. 
Ho  ;  ej  »  Hi  ;  e)  ■  T  (9) 

by  inversion  on  (d:Thread)  with  (3)  on  some  thread  j  such  that  j  e  {0, ...,  77}. 
For  clarity  we  now  rewrite  some  of  the  above  to  reflect  e/. 

r0  I  A7,A/7  ,A'  h  H0  (10) 

Ao 

by  rewriting  (1). 

r0  I  Ay-,A;rh^:![]H-  (11) 

A°; 


by  rewriting  (4). 


T0,  Tj  |  A[  h  e'  :  ![]  H  • 

r0,r,  1  A[,AjT,A'  \-  Hi 

r0,ri  I  a jT  h  v 


(12) 

(13) 

(14) 

by  (Expression  Preservation)  with  (10),  (1 1),  and  (9). 


Thus,  we  conclude  by  (wf:Program)  with  (12),  (13),  (14)  and  (4)  to  accommodate  the  remaining 
threads  in  T0  combined  with  weakening  the  lexical  environment  to  include  Ti.  □ 
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Theorem  6  (Expression  Preservation).  If  we  have 


To  I  A0,  At,  A2  \-  H0  r0  |  A(),  AT  \-  eQ  :  A  H  A 


H0  ;  eg  >->  Hi  ;  e\  ■  T 


then,  for  some  A]  and  Fu  we  have 


To.  Ti  I  Ai,  At,  A2  I-  H[ 


f"i  |  A[  l-  e\  :  A  H  A 


Ti  I  At  I-  T 


Proof.  We  proceed  by  induction  on  the  typing  derivation  of  T0  |  A0  h  e0  :  A  H  A. 
Case  (t:Ref),  (t:Pure),  (t:Unit)  -  are  values  (no  step  available). 


Case  (t:Pure-Read),  (t:Linear-Read),  (t:Pure-Elim)  -  not  applicable,  environments  not  closed. 


Case  (t:New)  -  We  have: 


r0  |  A0  h  new  v  :  3/.(!ref  rw/A)  h  A  (1) 

r„  |  A0,  A2  l-  Hq  (2) 

Ho ;  <5[new  v]  ha  Hq  ,  p  e— >  v  ;  fi[p]  (3) 

by  hypothesis,  with  (d:New)  where  £  =  □  note  that  we  have  Ar  =  •  since  there  is  no 
resulting  thread  from  this  step. 


I  n  I  An  h  v  :  A  H  A 


o  I 

To  t-  Ao  <:  Av,  A 
To  |  Av  l-  v  :  A  H  • 

p  fresh 

r0  I  A,,,  A,  A2  l-  Ho 

Thus,  if  we  make: 

Ti  =  p  :  loc 
We  have  that: 

To,  Ti  |  Av  l-  v  :  A  H 

by  (Weakening)  (6)  with  T i  (note  that  weakening  is  only  valid  in  the  lexical  environments,  T). 

r(),r,  |  Av,A,A2htf0  (ii) 

by  (str:Loc)  with  T i  (that  contains  p)  on  (8). 
r0,r!  |  A,A2,rwpA  h  Hq  ,  p  •=-»  v  (12) 

by  (str:Binding)  with  (10)  and  (11)  with  p. 


(4) 

by  inversion  on  (t:New)  with  (1). 

(5) 

(6) 

by  (Values  Lemma)  with  (4). 

(7) 

by  inversion  on  (d:New)  with  (3). 

(8) 

by  (str: Subsumption)  with  (2)  and  (5). 

(9) 

(10) 


Thus,  if  we  make: 
A]  =  A,  rw  p  A 
We  have  that: 
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(13) 


r0,  r,  |  •  f-  p  :  !refp  H  •  (14) 

by  (t:Ref)  with  p  and  (t:Pure). 
r0,r,  |  A!  hp:  !ref pH  A!  (15) 

by  (t:Frame)  on  (14)  with  A). 
|  Aj  h  p  :  !refp  ::  rwp  A  H  A  (16) 

by  (t:Cap-Stack)  on  (15)  noting  that  (13). 


If  /  fresh  then: 

r0,  T,  |  Ax  h  p  :  ( !ref  p  ::  rw p  A){p//}  H  A  (17) 

by  type  substitution  on  (14). 

Note  that,  by  (4),  p  cannot  occur  in  A  since  it  is  a  fresh  location  constant  not  present  in  r0. 
T0,Ti  |  Aj  h  p  :  3/.(!ref  / ::  rw/A)  H  A  (18) 

by  (t:  Sub  sumption)  together  with  (st:PackLoc)  on  (17). 


Thus: 

TcTj  |  Ax  hp  :  3/.(!ref  / ::  rw/A)  H  A  (19) 

for  some  Ai,Ti. 


by  (18). 

Therefore,  by  (12)  and  (19)  we  conclude  noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •. 


Case  (t:Delete)  -  We  have: 


1.  Case  where  p  is  not  shared  (and  thus  not  locked): 


T0 1  A()  h  delete  p  :  3/.A  h  A  (1) 

To  |  A0,  A2  h  Hq ,  p  c— >  v  (2) 

Hq  ,  p'  c — >  v  ;  <5[delete  p]  1 — >  Hq  ;  £[v]  (3) 

by  hypothesis,  with  (d:Delete)  where  <5  =  □.  Also  note  that  we  have  A 7-  =  •  since 
there  is  no  resulting  new  thread  from  this  step. 


T0  |  A0  h  p  :  3/.(!ref  /::  rw/A)  H  A 
To  h  A0  <:  Ap,  A 

T0  |  Ap  h  p  :  3/.(!ref  / ::  rw  /  A)  H  • 

To  |  Ap  h  p  :  (!ref  l ::  rw  l  A){p//}  H  • 

T0  |  Ap  h  p  :  !ref  p  ::  rw  p  A{p//}  H  • 

by  (ls: 

T0  |  Ap  h  p  :  !ref  pnrwp  A{p//} 

T0  h  Ap  <:  A',rwpA{p//} 

T0  I  A',  h  p  :  !ref  p  H  • 


(4) 

by  inversion  on  (t: Delete)  with  (1). 

(5) 

(6) 

by  (Values  Lemma)  with  (4). 

(7) 

by  (Values  Inversion)  with  (6). 

(8) 

.6),  (ls:2.10),  (ls:2.1),  (ls:2.12)  with  (7). 

(9) 

by  (Values  Inversion)  with  (8). 

(10) 

(11) 

by  (Values  Lemma)  with  (9). 

(12) 
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by  inversion  on  (t:Ref)  with  (11). 


Therefore: 


r0 

r0 

r„ 

r0 

r0 

To 


Ap,  rw  p  A{p/l},  A,  A2  h  H0,  p^v  i.e.: 

rw  p  A{p/l},  A,  A2  i-  //o  ,  p  c— >  v  (13) 

by  (str:Subsumption)  using  (2),  (10)  and  (12). 

(14) 

(15) 

by  (Store  Typing  Inversion)  with  (13). 

(16) 

by  (t:  Sub  sumption)  together  with  (st:PackLoc)  on  (15). 

(17) 

by  (t:Frame)  with  (16)  using  A. 


Av,  A,  A2  l-  Hq 
Av  h  v  :  A{p/l}  H  • 

Av  h  v  :  3/.A  H  • 

A,„  A  h  v  :  31. A  H  A 


Using: 

r,  =  • 

Aj  =  Av,  A 
We  have: 


(18) 

(19) 


T0,  Ti  |  Aj  h  v  :  31. A  h  A  (20) 

by  (17)  with  (18)  and  (19). 

T0,  Tj  |  A1?  A2  h  Hq  (21) 

by  rewriting  (14)  with  (18)  and  (19). 
Therefore,  by  (20)  and  (21)  we  conclude,  noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •. 


2.  Case  when  p  is  shared  (and  thus  the  location  is  locked  and  there  is  a  pending  guarantee) 
is  analogous  to  the  previous  case  except  for  the  use  of  (str:Dead-Locked)  at  the  end  to 
store  typing  the  resulting  environments  and  heap. 


Case  (t:Assign)  -  We  have: 


r<)  I  A0  1-  p  :=  Vi  :  A\  h  A,  rw  p  A0  (1) 

To  I  A0,  A2  1-  Hq  ,  p ■  c— >  v0  (2) 

Hq  ,  p1  Vo  ;  :=  Vi]  1— >  Hq  ,  p-  v  1  ;  fi[vo]  (3) 

by  hypothesis,  with  (d:  Assign)  where  S  =  □.  Also  note  that  we  have  AT  =  ■  since  there  is 
no  resulting  new  thread  from  this  step. 


T0  A0  1-  vj  :  Aq  h  A' 

(4) 

T0  |  A'  h  p  :  ref  p  H  A,  rw  p  A\ 

(5) 

by  inversion  on  (t: Assign)  with  (1). 

To  1-  Ao  <:  AVl,  A' 

(6) 

To  1  AVl  1-  Vi  :  Ao  h  • 

(7) 

by  (Values  Lemma)  on  (4). 

T0  h  A'  <:  Ap,  A,  rw  p  Ax 

(8) 

T0  |  Ap  h  p  :  refp  H  • 

(9) 

by  (Values  Lemma)  on  (5). 
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Ap  -  • 


r0  |  AV1,  A,rwp  Au  A2  h  Ho  ,  p? 

To  I  AVl,  AVo,  A,  A2  h  Ho 
To  I  A,,0  1-  Vo  :  A\  H  • 

r0  |  AV0,  A,  rw  p  Aq,  A2  h  H0  ,  p? 


(10) 

by  inversion  on  (t:Ref)  with  (9). 

vo  (11) 

by  (str:Subsumption)  with  (2),  (6),  (8)  and  (10). 

(12) 

(13) 

by  (Store  Typing  Inversion)  on  (11). 
vi  (14) 

by  (str:Binding)  with  p  on  (7)  and  (12). 


by  making: 

Ti  =  • 

To,  T 1  |  AVo,  A,  rw  p  Aq,  A2  1-  Hq  ,  p- 


Vl 


To,  T 1  |  AVo  l-  Vo  :  A\  H 


(15) 

(16) 

by  (Weakening)  with  (14). 

(17) 

by  (Weakening)  on  (13). 

(18) 

by  (t:Frame)  using  A,  rw  p  A0  with  (17). 

Therefore,  by  (16)  and  (18)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •). 

Case  (t:Dereference-Linear)  -  We  have: 


T0,  T j  |  AVo,  A,  rw p  A0  h  v0  :  A,  H  A,  rw p  Ac 


T0  I  A0  t  !p  :  A  h  A,  rw p  ![] 


To  I  A0,  A2  h  Hq  ,  p 


(1) 
(2) 

Hq  ,  p!  ^  v  ;  <5[!p]  Hq  ,  p!  v  ;  fi[v]  (3) 

by  hypothesis,  (d: Dereference)  where  <5  =  □.  Also  note  that  we  have  Ar  =  •  since  there  is 
no  resulting  new  thread  from  this  step. 


To  |  A0  b  p  :  ref  p  H  A,rwp  ![] 

To  h  A0  <:  Ap,A,rwp  A 
T0  |  Ap  h  p  :  ref  pH- 


A p  -  ' 


T0  h  A0  <:  A,rwp  A 

T0  |  A,rwp  A,  A2  h  H0,p- 

T0  |  Av  l-  v  :  A  H  • 

T0  |  A,  Av,  A2  h  Hq 

To  |  •  h  v  :  ![]  h  • 


(4) 

by  inversion  on  (t: Dereference- Linear)  with  (1). 

(5) 

(6) 

by  (Values  Lemma)  on  (4). 

(7) 

by  (Values  Inversion)  on  (6). 

(8) 

by  rewriting  (5)  with  (7). 

(9) 

by  (str:Subsumption)  with  (8)  and  (2). 

(10) 

(ID 

by  (Store  Typing  Inversion)  with  (9). 

(12) 

by  (t:Unit)  with  value  v. 
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r0  I  A,  Av,  rw  p  ![],  A2  h  H0  ,  p?  «=-» 
by  making: 

r,  =  • 

r(),  r  1  I  A,  Av,  rw  p  ![],  A2  i -  H0,  p- 


(13) 

by  (str:Binding)  using  p,  (11)  and  (12). 

(14) 

(15) 


r<b  Tj  |  Av  l-  v  :  A  h  • 

r0, r,  I  Av,  A, rw p  ![]  I-  v  :  A  h  A,  rwp  ![] 


by  (Weakening)  using  Ti  on  (13). 

(16) 

by  (Weakening)  using  Ti  on  (10). 

(17) 

by  (t:Frame)  using  A,  rw  p  ![]  on  (16). 

Therefore,  by  (15)  and  (17)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •)• 

Case  (t:Dereference-Pure)  -  We  have: 

r0  |  A0  h  !p  :  !A  H  A,  rw  p  !A  (1) 

r0 1  Ao,  A2  1*  Hq  ,  p?  c  >  v  (2) 

Hq  ,  p?  v  ;  !p  i->  H0  ,  p-  v  ;  £[v]  (3) 

by  hypothesis,  with  (d: Dereference)  where  £  =  □.  Also  note  that  we  have  Ar  =  •  since 
there  is  no  resulting  new  thread  from  this  step. 


r0  |  A0  h  p  :  ref  p  H  A,  rw  p  !A 

r()  h  A0  <:  Ap,  A,  rw  p  !A 
T0  I  Ap  h  p  :  refp  h  • 


T0  h  A0  <:  A,rw  p  !A 

r()  |  A, rwp  !A,  A2  h  H0  ,  p? 

r0  |  Av  h  v  :  !A  h  • 

T0  I  A,  Av,  A2  1-  Hq 

Av  =  • 

To  |  •  h  v  :  IA  H  • 

To  |  A,  A2  h  Hq 
by  making: 

r,  =  • 

r0,  Tj  |  A,  rw  p  LA,  A2  h  H0  ,  p? 


(4) 

by  inversion  on  (t:Dereference-Pure)  with  (1). 

(5) 

(6) 

by  (Values  Lemma)  on  (4). 

(7) 

by  (Values  Inversion)  on  (6). 

(8) 

by  rewriting  (5)  with  (7). 

(9) 

by  (str:Subsumption)  with  (8)  and  (2). 

(10) 

(11) 

by  (Store  Typing  Inversion)  with  (9). 

(12) 

(13) 

by  (Values  Inversion)  on  (10). 

(14) 

by  rewriting  (11)  with  (12). 

(15) 

(16) 

by  (Weakening)  using  Ti  on  (9). 


139 


To,  T]  |  •  l-  v  :  !A  H  • 


(17) 

by  (Weakening)  using  Ti  on  (13). 
r0,  Tl  |  A,  rw  p  !A  h  v  :  !A  H  A,  rw  p  !A  (18) 

by  (t:Frame)  using  A,rw  p  !A  on  (17). 

Therefore,  by  (16)  and  (18)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •). 

Case  (t:Record)  -  is  a  value. 


Case  (t:Selection)  -  We  have: 


To  I  Ao  b  {f  —  v}.f,-  :  A,  h  A 
To  I  A0,  A2  i-  //() 


(1) 

(2) 

(3) 


H0  ;  <5[{f  =  v}.fj  ^  H0  ;  £[v«] 
by  hypothesis,  with  (d:Selection)  where  <5  =  □.  Also  note  that  we  have  AT  =  •  since  there 
is  no  resulting  new  thread  from  this  step. 

(4) 

by  inversion  on  (t:Selection)  with  (1). 

r„hA0<:A',A  (5) 

(6) 

by  (Values  Lemma)  on  (4). 

(7) 

by  (Values  Inversion)  with  (6)  . 

(8) 

by  (t:Frame)  with  A  with  (7). 

r„  I  A\  A,  A2  b  H()  (9) 

by  (str: Subsumption)  with  (2)  and  (5). 

Therefore,  by  making: 


r„  I  Ao  h  {f  =  v)  :  [f  :  A]  h  A 

C)  I-  A0  <:  A',  A 

r„  |  A'  h  {f^}  :  [£7A]  h  • 

To  I  A'  l-  V,-  :  Aj  H  • 

r0  |  A',  A  h  Vi  :  A;  H  A 


n  =  •  (io) 

Ai=A',A  (11) 

r0,r1|A1,A2h7/o  (12) 

by  (Weakening)  with  (10)  on  (9)  and  rewriting  (9)  using  (11). 
r0,r,  |  Aj  h  Vi  :  A,-  H  A  (13) 

by  (Weakening)  with  (10)  on  (8)  and  rewriting  (8)  using  (11). 


Therefore,  by  (12)  and  (13)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •)• 


Case  (t:Application)  -  We  have: 

T0  |  A0  h  (Ax.e)  v  :  Ai  H  A 
To  I  A0,  A2  I-  H0 
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(1) 

(2) 


Hq  ;  8[(Ax.e)  v]  h>  Hq  ;  S[e{v/*}]  (3) 

by  hypothesis,  with  (d: Application)  where  <5  =  □.  Also  note  that  we  have  A7-  =  •  since  there 
is  no  resulting  new  thread  from  this  step. 


r„ 

r„ 

r„ 

r„ 

r0 

r„ 

r„ 

V  = 

r„ 

r0 

r„ 


A0  h  Ax.e  :  Ao  — °  Aj  h  A' 
A'  h  v  :  A0  h  A 

h  A0  <:  A',AV 
Av  h  Ax.e  :  Ao  ~ °  A]  H  • 

h  A'  <:  A,  A;, 

A'  l-  v  :  A0  H  • 

A„,  x  :  A0  h  e  :  Ai  H  • 

Ax.e 

a;,,  Av,  A  h  V  :  A0  h  Av,  A 
Av,  x  :  Ao,  Ahe:A|  H  A 
Av,  A'  A  h  e{v/4  :  A]  H  A 


By  making: 

r,  =  • 

Aj  =  Ay,  a;,  A 
We  immediately  have: 
r0,r,  |  A[  i-  e{v!x}  :  Aj  h  A 


To,  r i  |  A',  Av,  A2  i-  Hq 
To,  r  1  |  A,  A',  Ay,  At  l-  Hq 

r0,  Tj  |  Ai,  A2  l-  Hq 


(4) 

(5) 

by  inversion  on  (t: Application)  with  (1). 

(6) 

(7) 

by  (Values  Lemma)  on  (4). 

(8) 

(9) 

by  (Values  Lemma)  on  (5). 

(10) 

(ID 

by  (Values  Inversion)  with  (7). 

(12) 

by  (t:Frame)  on  (9)  with  Av,  A. 

(13) 

by  (t:Frame)  on  (10)  with  A. 

(14) 

by  (Substitution  Lemma  -  Linear)  with  (12)  and  (13). 


(15) 
with  (14). 

(16) 

by  (str: Subsumption)  with  (2)  and  (6). 

(17) 

by  (str: Subsumption)  with  (16)  and  (8). 

(18) 

by  renaming  the  environment. 

Therefore,  by  (15)  and  (18)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •). 


Case  (t:Function)  -  is  a  value. 


Case  (t:Cap-Elim)  -  Not  applicable,  environment  not  closed. 


Case  (t: Cap-Stack)  -  We  have: 
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To  I  A0,  At  I-  e0  :  A0  ::  A\  H  A 
To  I  Ao,  At,  A2  1-  //o 
Ho  ;  e0  i->  H\  \  e\-T 

To  I  A0,  At  eo  :  A0  H  A,Aj 

r0,r!  |  Ai,Ar,A2 1-  //j 
r0,ri  |  Ai  h  ei  :  Ao  H  A,Ai 
r0,Ti  |  Ar  h  r 
for  some  A^T^ 

r0,Ti  I  A\  h  e\  :  A0  ::  Aj  h  A 

Therefore,  by  (5),  (7)  and  (8)  we  conclude. 

Case  (t: Cap-Unstack)  -  We  have: 

To  I  A0,  At  Co  :  A0  H  A,Ai 
To  I  Ao,  At,  A2  1-  Ho 
Ho  ;  Co  i->  H 1  ;  e\  ■  T 

T0  |  A0  h  e0  :  A0  ::  Ax  h  A 

r0,Ti  |  Ai,Ar,  A2  l-  H\ 
r0,Ti  |  Ai  h  e\  :  Ao  ::  Ai  H  A 
To.Ti  |  At  V  T 
for  some  A^To 

r0,r!  |  A\  l-  e\  :  A0  h  A,  A] 

Therefore,  by  (5),  (7)  and  (8)  we  conclude. 

Case  (t: Subsumption)  -  We  have: 

To  I  A0,  A t  1-  Co  :  Ai  H  A 
To  I  Ao,  At,  A2  h  Ho 
Ho  ;  Co  i->  H\  ;  C]  T 

To  1-  A0,  A r  <:  A',,  A'r 
To  I  Aq,  A'r  l-  Co  :  A0  H  A' 

C)  1-  Ao  <:  A] 

T0  h  A'  <:  A 


(1) 

(2) 

(3) 

by  hypothesis. 

(4) 

by  inversion  on  (t:Cap-Stack)  on  (1). 

(5) 

(6) 

(7) 

by  induction  hypothesis  on  (2),  (3)  and  (4). 

(8) 

by  (t:Cap-Stack)  on  (6). 


(1) 

(2) 

(3) 

by  hypothesis. 

(4) 

by  inversion  on  (t:Cap-Unstack)  on  (1). 

(5) 

(6) 

(7) 

by  induction  hypothesis  on  (2),  (3)  and  (4). 

(8) 

by  (t:Cap-Unstack)  on  (6). 


(1) 

(2) 

(3) 

by  hypothesis. 

(4) 

(5) 

(6) 
(7) 

by  inversion  on  (t:Subsumption)  with  (1). 
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r„  |  Aq,  a't,  a2  i-  Hq  (8) 

by  (str: Subsumption)  with  (2)  and  (4). 

r0,r,  |  a1;  A'r,  a2  i-  Hi  (9) 

r0,r,  I  A!  he!  :A()h  A'  (10) 

r0,r,  |  A'r  h  r  (ii) 

for  some  A^r^ 

by  induction  hypothesis  on  (3),  (5)  and  (8). 
TotTi  |  Ai  h  ei  :  A]  h  A  (12) 

by  (t: Subsumption)  with  (6),  (7)  and  (10). 
r„,r!  |  Ar  h  r  (13) 

by  (wf: Program)  and  (t: Subsumption)  with  (11)  and  (4). 

r0,r,  |  Ai,  Ar,  a2  h  h{  (14) 


by  (2)  and  (4)  since  A T  is  disjoint,  its  support  on  H\  remains  by  (str:Subsumption)  from  (2). 
Therefore,  by  (14),  (12)  and  (13)  we  conclude. 

Case  (t:Tag)  -  is  a  value. 


Case  (t:Case)  -  We  have: 


T0 1  A0  h  case  t,#v,  of  t j#xj  — >  ej  end  :  A  h  A  (1) 

r0|  A0,A2  h  H0  _  (2) 

Hq  ;  <5[case  t,#v,  of  t j#xj  — >  e  j  end]  h->  H0  ;  v,/.v',}J  (3) 

by  hypothesis,  (d:Case)  where  £  =  □.  Also  note  that  we  have  Ar  -  ■  since  there  is  no 


resulting  new  thread  from  this  step. 
To  |  A()  h  t/#V;  :  Yji  t(#A/  H  A' 
r0  |  A',  Xi  :  A,-  h  et  :  A  H  A 

i<i 

To  I-  A0  <:  A,,,  A' 

r0  |  Av  h  t,#v,  :  2/ 1 ,-#A,-  H  • 

T0  I  Av  h  v,-  :  A,-  H  • 
for  some  i. 


(4) 

(5) 

(6) 

by  inversion  on  (d:Case)  with  (1). 

(7) 

(8) 

by  (Values  Lemma)  with  (4). 

(9) 


by  (Values  Inversion)  with  (8). 

r0  |  Av,  A'  h  Vi  :  A,  H  A  (10) 

by  (t:Frame)  on  (9)  with  A'. 

T0  |  A0  h  eAvi/xi)  :  A  H  A  (11) 

by  (Substitution  Lemma  -  Linear)  with  (10)  and  (5),  for  some  i. 

By  making: 

r,  =  • 

Aj  =  A0 

We  trivially  have: 
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r(),  r J  I  A!  h  etiVi/.Xi}  :  A  H  A 


(12) 

by  (11). 

r0,r,  |  a1;  a2  i-  Ho  (13) 

by  (2). 

Thus,  by  (12)  and  (13)  we  conclude  (noting  that  T  is  empty  meaning  that  we  also 
have  At  =  •). 


Case  (t:Alternative-Left)  -  We  have: 


To  I  A(),A0  ©  A\,  At  I-  Co  :  A2  H  A  (1) 

T0  |  A0,A0©A1,Ar,A2  h  H0  (2) 

Ho  ;  e0  *—>  H\\  e\  T  (3) 

by  hypothesis. 

r0  I  Aq,Aq,At  l-  e0  :  A2  h  A  (4) 

To  I  Ao,Ai,At  \-  e0  :  A2  H  A  (5) 

by  inversion  on  (t: Alternative-Left)  with  (1). 
By  (Store  Typing  Inversion)  on  (2),  we  have  that  either: 

•  To  |  Ao,  Ao,  At,  A2  f-  Ho  (1.1) 

by  sub-case  hypothesis. 

To,r,  |  Al,AT,A2^Hl  (1.2) 

r0,Ti  |  Ai  l-  e\  :  A2  H  A  (1.3) 

To,Ti\At\-T  (1.4) 

for  some  Ai,Ti. 

by  induction  hypothesis  with  (1.1),  (3)  and  (4). 

Therefore,  we  conclude. 

•  T0  |  A0,Ai,At,A2  1-  Ho  (2.1) 

analogous  to  previous  sub-case  but  using  (5). 

Thus,  we  conclude. 


Case  (t:Intersection-Right)  -  We  have: 


To  |  Ao,  A t  1-  Co  :  At  H  A,  A0&A1  (1) 

To  I  A0,  AT,  A?  1-  Ho  (2) 

H{)  ;  eo  i->  H\  ;  e\  T  (3) 

by  hypothesis. 

To  |  Ao  l-  eo  :  A2  -1  A,  Ao  (4) 

To  |  Ao  I-  cq  :  A2  H  A,  A]  (5) 

by  inversion  on  (t: Intersection- Right)  with  (1). 

r0,r1|A1,Ar,A2h//1  (6) 

r0,r!  |  A[  1-  e\  :  A2  H  A,  A0  (7) 

r0,Ti  |  Ar  h  r  (8) 

by  induction  hypothesis  with  (2),  (3)  and  (4). 

r0,r,  |  a1,at,a2\-h1  (9) 
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r0,r!  |  Ai  l-  e\  :  A2  h  A,  A] 
r0,Ti  |  At  h  T 

r0,Ti  |  Ai  l-  e\  :  A?  H  A,  Ao&Aj 
Thus,  by  (11),  (12)  and  (9)  we  conclude. 
Case  (t:Frame)  -  We  have: 


(10) 

(ID 

by  induction  hypothesis  with  (2),  (3)  and  (5). 

(12) 

by  (t: Intersection- Right)  on  (7)  and  (10). 


r0  I  A0,  At,  A2  l-  e0  :  A  H  A,  A2 
To  I  A0,  At,  A2,  A3  h  H0 
Ho  ;  <?o  |— ^  7/ 1  ;  e\  ■  T 

r0  I  Ao,  Ar  h  eo  :  A  H  A 

r^r,  |  A\,at,  a2,  a3  i- 
To,  Tj  |  Ai  l-  ei  :  A  H  A 
r0,Ti  |  Ar  h  r 

To,  T]  |  Ai,  A2  l-  e\  :  A  h  A,  A2 
Therefore,  by  (5),  (8),  and  (7)  we  conclude. 


(1) 

(2) 

(3) 

by  hypothesis. 

(4) 

by  inversion  on  (t:Frame)  with  (1). 

(5) 

(6) 

(7) 

by  induction  hypothesis  on  (2),  (3)  and  (4). 

(8) 

by  (t:Frame)  on  (7)  using  A2. 


Case  (t:Let)  -  We  have  two  reductions: 
1 .  Sub-Case:  8  =  □ 


r0 

To 

Ho 


A0  h  let  a  =  v  in  e  end  :A!  h  A  (1) 

A„,A2h  Ho  (2) 

;  fi[let  x  =  v  in  e  end]  i->  H0  ;  fi[e{v/.v}]  (3) 

by  hypothesis,  (d:Let)  where  8  =  □.  Also  note  that  we  have  A-r  =  •  since  there  is 
no  resulting  new  thread  from  this  step. 

A0  i-  v  :  A0  H  A'  (5) 


o 


A' ,x  :  Aq\-  e  \  A\  H  A 


To  I-  Ao  <:  Av,  A' 
r0  |  Av  h  V  :  A0  H  • 

r0  |  Av,  A'  h  v  :  A0  H  A' 

r0  |  Av,  A'  h  e{v/x}  :  Ai  H  A 

r0  I  Av,  A',  A2  l-  Ho 


(6) 

by  inversion  on  (t:Let)  with  (1). 

(7) 

(8) 

by  (Values  Lemma)  with  (4). 

(9) 

by  (t:Frame)  with  (8). 

(10) 

by  (Substitution  Lemma  -  Linear)  with  (6)  and  (9). 

(ID 
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by  (str: Subsumption)  with  (2)  and  (7). 
Therefore,  by  (Weakening)  with  Ti  =  •  and  by  (10)  and  (1 1)  we  conclude. 


2.  Sub-Case:  £  =  (let  x  =  £'[e0\  in  e2  end) 


r0  |  A0,  At  i-  let  a  =  £'[<?()]  in  e2  end  :  Ax  h  A 

(1) 

To  |  A(),  At,  A2  i-  Ho 

(2) 

Ho  ;  £'[e0]  »  H{  ;  ■  T 

(3) 

by  hypothesis. 

To  |  Aq,  At  I-  fi'feo]  :  A0  H  A' 

(4) 

r0  1  A',  x  :  A0  t  e2  :  A[  H  A 

(5) 

by  inversion  on  (t:Let)  with  (1). 

To,  Ti  |  Ai,  At,  A2  \-  Hi 

(6) 

r0,  Tj  |  Ai  h  £’[e\\  :  A0  H  A' 

(7) 

Tq,  Ti  |  At  T 

(8) 

by  induction  hypothesis  on  (2),  (4)  and  (5). 

To,  Ti  |  A',x  :  A0  I-  e2  :  Aj  h  A 

(8) 

by  (Weakening)  on  (6). 

r0,  Ti  1  Ai  h  let  x  =  £’[ei\  in  e2  end  :A|  h  A 

Therefore,  by  (6),  (8),  (9)  we  conclude. 

(9) 

by  (t:Let)  with  (7)  and  (8). 

Case  (t:Fork)  -  We  have: 

Tq  |  At  h  fork  c  :  ![]  h  • 

T0  |  At,  A2  Hq 

H0 ;  <5[fork  e]  ^  H0;  £[{}]•  e 
To  I  At  h  e  : ![]  H  • 
r0  I  •  h  {}:![]  h  • 

Thus,  by  making: 

A]  =  • 

We  conclude  by  (2),  (4)  and  (5). 

Case  (t:Forall-Loc-Val),  (t:Forall-Type-Val)  -  Are  values. 

Case  (t:TypeOpenBind),  (t:LocOpenBind)  -  Not  applicable,  environment  not  closed. 
Case  (t:LocOpenCap)  -  We  have: 


(1) 

(2) 

(3) 

by  hypothesis,  with  (d:Fork)  where  £  =  □. 

(4) 

by  inversion  on  (t:Fork). 

(5) 

by  (t:Record). 


(6) 
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To  I  A0,  AT,3l.Ao  I-  e0  :  A\  h  A 
r0  |  Ao,  Aj,  3/.Ao,  A2  l-  Hq 
Hq  ;  e0  i->  H\\  e\  T 


To,  1 1  loc  |  Aq,  A^,  Aq  I-  •  A]  H  A 
To  I  A0,  At,  Ao{p/l},  A2  1-  //q 


(1) 
(2) 

(3) 

by  hypothesis. 

(4) 

by  inversion  on  (t:LocOpenCap)  with  (1). 

(5) 

by  (Store  Typing  Inversion)  with  (2). 
To  I  Ao,  At,  Ao{p/l}  \-  eo  '■  A]  H  A  (6) 

by  (Substitution  Lemma  -  Location  Variable)  with  p  and  (4). 
r0,r,  I  A1,Ar,A2h//1  (7) 

To,Ti  |  Aj  l-  e\  :  A0  H  A'  (8) 

r0,r,  |  Ar  h  r  (9) 

by  induction  hypothesis  with  (3),  (5)  and  (6). 

Thus,  we  conclude. 


Case  (t:TypeOpenCap)  -  Analogous  to  (t:LocOpenCap). 


Case  (t:Unlock-Guarantee)  -  We  have: 


r0  |  A0,  A0,  A0;  Aj  h  unlock  v  : ![]  H  Ap.Ai  (1) 

To  I  A0,  A0,  A0;Ai,  A2  i-  H0,pm  c— >  v  (2) 

Ho,p*  v  ;  <5[unlockp]  i->  H0,p  c— >  v  ;  £[{}]  (3) 

by  hypothesis  with  (t:Unlock-Guarantee)  where  £  =  □  and  where  A7-  =  •  since  there  is  no 
resulting  new  thread  from  this  step. 

To  I  Ao,Ai  h  {}  :  ![]  H  Ao,Ai  (4) 

by  (t:Record),  (t:Pure),  and  (t:Frame)  with  A0,A]. 


If  we  make: 


Hq  =  H,H'  (5) 

then: 

locs(Ao)  =  locs(Ai)  =  p  (6) 

p*  <=-»  v  6  //,p*  v  (7) 

r|A0h/7,^n;  (8) 

p  t— >  v  e  H,p  <=-»  v  (9) 

T  |  A0  h  H,p~^~v  (10) 

r|Ao,A!  vH,H',p^v  (11) 


by  (Store  Typing  Inversion)  with  (2). 

Therefore,  we  conclude  by  (4)  and  (11)  noting  (5). 


Case  (t:Lock-Rely)  -  We  have: 


To  I  A0,  Aq  =>  A\  I-  lock  v  :  ![]  h  A0,  A0,  Aj 


(1) 
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To  I  A0,A()  =>  A\,  A2  l-  Ho,p 


(2) 

(3) 


H0,p  c— >  v  ;  £[lock  p]  //o,p*  e— ; >  v  ;  £[{}] 

by  hypothesis,  with  (t:Lock-Rely)  where  £  =  □.  and  where  AT  =  •  since  there  is  no 
resulting  new  thread  from  this  step. 

r0  |  A0,A(),Ai  1-  {}:![]  H  A0,Ao,Ai  (4) 

by  (t:Record)  and  (t:Frame)  with  A0,  A0.  A  1 . 
locs(A0)  =  p  (5) 

by  inversion  on  (t:Lock-Rely)  since  p  e  A0. 
r0  |  A0  h  (6) 

Ho  =  H,H'  _  (7) 

by  (Store  Typing  Inversion)  with  (2),  since  we  know  that  the  locations  p  (thus  the  rely  type 
must  be  supported  by  the  heap  since  protocols  must  be  introduced  via  (str:Subsumption)). 
We  must  show  that: 


To  I  Ao,Ao,Ai,A?  1-  H,H',p *  e— »  v 

Since  A0  =>  Ai  is  well-formed  and  also  obeys  protocol  composition,  we  have  that  A!  must 


have  one  of  the  following  structures: 

•  A,  =  (A  1 ;  A")  (8.1) 

Thus,  if  we  have  a  heap  such  that: 

T0  |  A)  h  H",p~^v  (8.2) 

T()  |  A0,A",  A2  h  H",  H,p^ v  (8.3) 

by  (Composition  Preservation)  and  (2)  since  we  know  that  all  protocols  must  still  compose 
after  stepping. 

To  I  Ao,  Ao,  Ai,  A2  1-  H,H',pm  c— >  v  (8.4) 

by  (str:Locked)  using  (6),  (7),  (8.2)  and  (8.3). 

•  Al=\/l.A\  (9.1) 

Thus,  if  we  have  a  heap  such  that  (similar  to  previous  case): 

T0,  / :  loc  |  A)  h  H",p~^Tv  (9.2) 

Then  by  (str:Locked): 

To,  / :  loc  |  Ao,A„,A;  h  H,H',pr^  (9.3) 

and: 

T„  |  A o,A(),V/.A;  h  (9.4) 

by  (str:ForallLocs). 

•  A\  =  VXcA'.A'  (10.1) 

r0  |  Ao.Aq.VXcA'Aj  h  H,H',p •  ^  v  (10.2) 


similarly  to  the  previous  case  but  using  (str:ForallTypes). 
Therefore,  we  conclude  by  (4)  and  (8.4),  (9.4),  (10.2). 


□ 
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H.10  Progress 

We  define  progress  over  closed  programs  (which  includes  an  arbitrarily  large  but  finite  number  of 
thread,  T)  and  expressions  (e). 

Theorem  7  (Program  Progress).  If  we  have 

r  |  A  h  T0  live(7o) 

and  if  exists  H0  such  that  T  |  A  h  H0  then 


Ho  To  ^  Hi  ;  T\ 

Proof.  We  proceed  by  induction  on  the  typing  derivation  of  f  |  A  h  70. 


Case  (wf: Program)  -  We  have: 

r  |  A  h  To 
li  ve(r0) 


r  |  A,h  c,  : ![]  H 
i  e  {0,  ...,n} 
n  >  0 

To  =  So  •  •••  •  A; 
A  =  Ao, A„ 


(1) 
(2) 

by  hypothesis. 

(3) 

(4) 

(5) 

by  inversion  on  (1)  with  (wf: Program). 

(6) 

(remember  that  the  order  of  the  threads  is  not  important) 

(7) 

by  decomposing  A  into  smaller  typing  environments. 

Then  for  some  arbitrary  j  such  that: 

j  €  {0, ...,«}  (8) 

live(ey)  (9) 

by  (2)  and  the  definition  of  live(T0)  there  must  be  at  least  one  thread  that  is  live. 
Then  by  (Expression  Progress)  with  ej  on  (3),  we  have  that  either: 

•  ej  is  a  value,  or  (10.1) 

•  if  exists  Ho  such  that  T  |  A  l-  H0  (note  that  A  j  e  A  by  (7))  then  either: 

o  (steps)  H0  ;  ej  i->  H\  ;  <?'■  •  T'  (10.2) 

o  (waits)  Wait(//0,  ej)  (10.3) 

We  have  that  cases  (10.1)  and  (10.3)  cannot  occur  because  we  picked  such  that  live(e;). 
Therefore,  we  have  (10.2)  which  by  (d:Thread)  with  the  remaining  threads  of  To  still  steps. 

Thus,  we  conclude  since  we  have  that  the  set  of  threads  steps. 


□ 


Theorem  8  (Expression  Progress).  If  we  have 

r  |  A0  l-  Co  :  A  h  Ai 


then  we  have  that  either: 
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•  e0  is  a  value,  or; 

•  if  exists  H0  such  that  f  |  A,  A0  h  H0  then  either: 


-  (steps)  H0  ;  eo  i->  Hi  ;  ei  •  T 

-  (waits)  Wait(//0,  e0) 

Proof.  We  proceed  by  induction  on  the  typing  derivation  of  Y  |  A0  I-  e0  :  A  H  A], 
Case  (t:Ref),  (t:Pure),  (t:Unit)  -  are  values. 


Case  (t:Pure-Read),  (t:Linear-Read),  (t:Pure-Elim)  -  not  applicable  due  to  the  environment  not 
being  closed. 

Case  (t:New)  -  We  have: 

r  |  A0  h  new  v  :  3/.(!ref  / ::  rw  l  A)  H  Ai  (1) 

by  hypothesis. 

new  v  is  not  a  value.  If  exists: 

r  |  A,  A0  b  Ho  (2) 

Then  the  expression  steps  using  (d:New)  with  £  =  □,  i.e.: 

□  [new  v]  (3) 

Thus,  we  conclude  by  stepping  using  (d:New). 

Case  (t:Delete)  -  We  have: 

T  |  A0  h  delete  v  :  31.A  h  Ai  (1) 

by  hypothesis. 

T  |  A0  h  v  :  3/.(!ref  / ::  rw  l  A)  H  Ai  (2) 

by  inversion  on  (t: Delete)  with  (1). 

T  |  Av  h  v  :  3/.(!ref  / ::  rw  /  A)  H  •  (3) 

T  h  A0  <:  A',AV  (4) 

by  (Values  Inversion)  with  (2). 

T  |  Av  h  v  : !ref  p  ::  rw p  A  H  •  (4) 

by  (Values  Inversion)  with  (3). 

T  |  Av  h  v  :  !ref  p  H  rw  p  A  (5) 

by  (Values  Inversion)  with  (4). 

T  |  A'  h  v  :  ref  p  H  •  (6) 

T  h  Av  <:  A(„  rw  p  A  (7) 

by  (Values  Inversion)  with  (5). 

a;.  =  •  (8) 
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per  (9) 

v  —  p  (10) 

by  (Values  Inversion)  on  (6). 

Since  delete  v  is  not  a  value.  If  exists: 

r  |  A,  A0  b  H0  (11) 

Then  we  must  have  that: 

p?  ^  v'  e  H0  (12) 

by  (Store  Typing  Inversion)  on  the  p  binding  and  (11),  (4)  and  (7). 
Then  the  expression  steps  using  (d:Delete)  with  £  =  □.  i.e.: 

□[delete  v]  (3) 

Thus,  we  conclude  by  stepping  using  (d:Delete). 

Case  (t:Assign)  -  We  have: 

T  |  A0  h  v0  :=  vi  :  Ai  H  Ai,rwpA0  (1) 

by  hypothesis. 

T  |  A0  h  vi  :  Aq  h  A2  (2) 

T  |  A2  e  v0  :  ref  p  h  Al5  rw p  A{  (3) 

by  inversion  on  (t: Assign)  with  (1). 
v0  =  P  (4) 

by  applying  (Values  Inversion)  multiple  times,  similarly  to  the  (t:Delete)  case,  on  (3). 
v0  :=  vi  is  not  a  value.  If  exists: 

T  |  A,  A0  b  Ho  (5) 

Then  we  must  have  that: 

p  e— »  v'  e  Ho  (6) 

by  (Store  Typing)  definition  on  the  p  binding  since  the  capability  for  p  exists. 
Then  the  expression  steps  using  (d: Assign)  with  £  =  □,  i.e.: 

□[v0  :=  vi]  (7) 

Thus,  we  conclude  by  stepping  using  (d:Assign). 

Case  (t:Dereference-Linear)  -  We  have: 

T  |  A0  h  !v  :  A  H  A1;rwp  ![]  (1) 

by  hypothesis. 

T  |  A0  h  v  :  ref  pH  AbrwpA  (2) 

by  inversion  on  (t: Dereference- Linear)  with  (1). 
v  =  p  (3) 

by  (Values  Inversion)  on  (2)  as  in  previous  cases. 

v0  :=  Vi  is  not  a  value.  If  exists: 

r  |  A,  A0  h  Ho  (5) 

Then  we  must  have  that: 

p?  c— >  v'  €  Ho  (6) 

by  (Store  Typing)  definition  on  the  p  binding  as  in  previous  cases. 
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Then  the  expression  steps  using  (d: Dereference)  with  £  =  □,  i.e.: 

□  [!v] 

Thus,  we  conclude  by  stepping  using  (d: Dereference). 


(7) 


Case  (t:Dereference-Pure)  -  similar  to  (t: Dereference-Linear). 
Case  (t:Record)  -  is  a  value. 


Case  (t:Selection)  -  We  have: 

T  |  A()  h  v.f,-  :  At  H  Ai  (1) 

by  hypothesis. 

T  |  A0  h  v  :  [f  :  A]  H  A!  (2) 

by  inversion  on  (t:Selection)  with  (1). 
v  =  {f  =  v'}  (3) 

by  (Values  Lemma)  and  (Values  Inversion)  with  (2). 

v.f,  is  not  a  value.  If  exists: 

T  |  A,  A0  b  H0  (5) 

Then  the  expression  steps  using  (d:Selection)  with  £  =  □,  i.e.: 

□  [v.f,]  (6) 

Thus,  we  conclude  by  stepping  using  (d: Selection). 

Case  (t:Application)  -  We  have: 

r  |  Ao  l-  Vo  Vi  :  A\  H  Ai  (1) 

by  hypothesis. 

T  |  Ao  l-  vo  :  Ao  A\  H  A2  (2) 

T  |  A2  h  vi  :  A0  H  Aj  (3) 

by  inversion  on  (t: Application)  with  (1). 
Vo  =  Ax.e  (4) 

by  (Values  Lemma)  and  (Values  Inversion)  with  (2). 

Vo  Vi  is  not  a  value.  If  exists: 

T  |  A,  A0  b  H0  (5) 

Then  the  expression  steps  using  (d:Selection)  with  £  =  □,  i.e.: 

□  [Vo  Vi]  (6) 

Thus,  we  conclude  by  stepping  using  (d: Application). 

Case  (t:Function)  -  is  a  value. 


Case  (t:Cap-Elim)  -  not  applicable  due  to  the  environment  not  being  closed. 
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Case  (t: Cap- Stack),  (t:  Cap-Unstack)  -  immediate  by  direct  application  of  the  induction  hypothe¬ 
sis  on  the  inversion  of  the  typing  rule. 


Case  (t:Frame)  -  We  have: 


r  |  Ao,  A2  b  Co  :  Ao  H  Aj,  A2  (1) 

by  hypothesis. 

r  |  A0  h  cq  :  A0  h  Aj  (2) 

by  inversion  on  (t:Frame)  with  (1). 
Then,  by  induction  hypothesis  on  (2),  we  have  that  either: 

•  c0  is  a  value,  or;  (3) 

•  if  exists  Ho  such  that  T  |  A,  A0  l-  Hq  then  either: 

o  (steps)  Hq  ;  c0  //1  ;  ci  •  T  (4) 

o  (waits)  Wait(//0>  c0)  (5) 


Therefore,  by  making  A2  G  A  by  (3),  (4),  and  (5)  we  conclude. 
Case  (t: Subsumption)  -  We  have: 


r  |  A0  h  Co  :  Aj  H  A3  (1) 

by  hypothesis. 

r  b  Ao  <:  A!  (2) 

r  |  Aj  h  c0  :  Ao  H  A2  (3) 

T  b  A0  <:  A!  (4) 

r  b  A2  <:  A3  (5) 

by  inversion  on  (t: Subsumption)  with  (1). 
Then,  by  induction  hypothesis  on  (3),  we  have  that  either: 

•  c0  is  a  value,  or;  (6) 

•  if  exists  H0  such  that  T  |  A,  Aj  b  Hq  then  either: 

o  (steps)  Ho  ;  c0  i-»  Hx  ;  ex  ■  T  (7) 

o  (waits)  Wait(//0,  £q)  (8) 

Furthermore,  we  know  that  if  exists  H'0  such  that: 

r  I  A,  Ao  b  H'0  (9) 

then: 

r  I  A,  Aj  b  //'  (10) 


by  (Subtyping  Store  Typing)  with  (2)  and  (6). 
Therefore,  we  conclude  by  (6),  (7)  and  (8)  (using  H'0). 

Case  (t:Tag)  -  is  a  value. 


Case  (t:Case)  -  We  have: 
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r  |  A0  h  case  v  of  t  j#xj  -»  e,  end  :Ah  A,  (1) 

by  hypothesis. 

r  1  Ao  h  V  :  z,  t Mi  h  A,  (2) 

r  |  At,Xj  :  A,-  l-  ej  :  A  H  A2  (3) 

i  <  j  (4) 

by  inversion  on  (t:Case)  with  (1). 
v  =  t,#v/  (5) 

by  (Values  Lemma)  and  (Values  Inversion)  with  (2). 
case  v  of  t j#Xj  — *  ej  end  is  not  a  value.  If  exists: 

r  |  A,  A0  b  H()  (6) 

Then  the  expression  steps  using  (d:Case)  with  £  =  □,  i.e.: 

□[case  v  of  t j#xj  —>  ej  end]  (7) 

Thus,  we  conclude  by  stepping  using  (d:Case). 


Case  (t:Alternative-Left)  -  We  have: 


T  |  A0,  A0  ©  A]  he'.  A  2  H  Ai  (1) 

by  hypothesis. 

T  |  A0,A0  h  e  :  A2  h  Ai  (2) 

T  |  Aq.Aj  h  e  :  A2  h  Ai  (3) 

by  inversion  on  (t: Alternative-Left)  with  (1). 

If  exists  H  such  that: 

T  |  A',  A„,A0  @A\hH  (4) 

By  (Store  Typing  Inversion)  due  to  (st:Alternative)  on  (4),  we  have  that  either  (from  © 
being  commutative): 

o  T|  A',A0,A0hH  (5) 

Then  by  induction  hypothesis  on  (2)  we  conclude. 
oTIAUo^hff  (6) 


Then  by  induction  hypothesis  on  (3)  we  conclude. 

Therefore,  we  conclude. 

Case  (t:Intersection-Right)  -  immediate  by  applying  the  induction  hypothesis  on  the  inversion 
of  the  typing  rule. 

Case  (t:Forall-Loc-Val),  (t:Forall-Type-Val)  -  are  values. 

Case  (t:LocOpenCap)  -  We  have: 

T  |  A0,  3 l.A\  h  e  :  Ai  H  A\ 

T,  l :  loc  |  Ao,  A\  h  e  :  A2  H  Ai 
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(1) 

by  hypothesis. 

(2) 


by  inversion  on  (t:LocOpenCap)  with  (1). 


If  e  is  not  a  value,  then  if  exists: 

r  |  A,  A0, 3l.Al  h  H0  (3) 

r  h  Ai{p/l)  <:  3l.A\  (3) 

by  (Store  Typing  Inversion)  on  (3)  and  (st:PackLoc)  with  31. A{. 

T  |  A0,Ai{p//}  h  c  :  A2  h  Aj  (4) 

by  (Substitution  Lemma)  on  (2)  with  p. 

Thus,  we  conclude  by  induction  hypothesis  on  (4). 

Case  (t:TypeOpenCap)  -  similar  to  (t:LocOpenCap). 

Case  (t:TypeOpenBind),  (t:LocOpenBind)  -  not  applicable  due  to  the  environment  not  being  closed. 

Case  (t:Fork)  -  We  have: 

T  |  A0  h  fork  e  : ![]  H  • 

fork  e  is  not  a  value.  If  exists: 

T  |  A,  A()  h  H0 

Then  the  expression  steps  using  (d:Fork)  with  8  =  □,  i.e 
□  [fork  e] 

Thus,  we  conclude  by  stepping  using  (d:Fork). 

Case  (t:Lock-Rely)  -  We  have: 

T  |  Ao,  Ao  =>  Ai  I-  lock  v  :  ![]  h  Ai,  Ao,  A]  (1) 

by  hypothesis. 

lock  v  is  not  a  value.  If  exists: 

r  |  A,  A0,A0  =>  Aj  h  H0  (2) 

By  (Store  Typing)  definition,  we  have  that  either: 

•  All  the  locks  of  the  locations  contained  in  A0  are  available.  Then  the  expression 
steps  by  (d:Lock)  with  8  =  □. 

•  Some  of  the  locks  of  the  locations  of  A0  are  unavailable.  Then  we  have  that  the 
expression  waits,  i.e.  we  have  Wait(//0>  lock  v). 

Thus,  we  conclude. 

Case  (t:Unlock-Guarantee)  -  We  have: 


(1) 

by  hypothesis. 

(2) 

(3) 


T  |  A0,  A0,  A0;Ai  h  unlock  v  : ![]  H  A0,  Ai 


(1) 

by  hypothesis. 


unlock  v  is  not  a  value.  If  exists: 
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(2) 


r  |  A(),A(),Ao;Ai  l-  Hq 

Then  the  expression  steps  using  (d:Unlock)  with  £  =  □,  i.e.: 

□  [unlock  v]  (3) 

Thus,  we  conclude  by  stepping  using  (d:Unlock). 

Case  (t:Let)  -  We  have: 

T  |  A0  h  let  jc  =  £>0  in  e2  end  :  A  h  A2  (1) 

by  hypothesis. 

T  |  A0  l-  c0  :  A0  h  Aj  (2) 

T  |  Al5  x  :  A0  l-  ^2  :  Ai  H  A2  (3) 

by  inversion  on  (t:Let)  with  (1). 

By  induction  hypothesis  on  (2),  we  have  that  either: 

•  c0  is  a  value;  (6) 

then  by  (d:Let)  the  expression  transitions,  with  £  =  □. 

•  if  exists  Hq  such  that  T  |  A,  A0  b  Hq  then  either: 

o  (steps)  Hq  ;  e0  Hx  ;  ex  ■  T  (7) 

then  the  expression  steps  by  (d:Thread)  (with  an  empty  initial  thread  pool)  and 
£  =  (let  x  =  £'[ci]  in  c2  end)  and  £'  =  □. 

o  (waits)  Wait(//0>  ^0)  (8) 

then  Wait  (Hq,  let  x  =  e0  in  e2  end)  by  the  definition  of  Wait  since  we  have: 
Wait(/70,  £[e0]) 

where  £  =  (let  t  =  £'[c0]  in  e2  end)  where  £'  =  □. 

Thus,  we  conclude. 


□ 
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I  Algorithms  Theorems 

We  now  discuss  the  algorithmic  implementations  of  protocol  composition  (shown  in  Section  F.l) 
and  subtyping  (shown  in  Section  F.2).  Namely,  we  discuss  the  decidability  of  these  algorithms. 
The  decidability  of  the  full  system  will  likely  require  annotated  terms  to  guide  the  type  system  in 
less  obvious  choices,  such  as  in  what  to  split  a  resource  and  when.  Although  they  did  not  do  a 
formal  discussion  of  decidability,  prior  work  on  rely-guarantee  protocols  [21]  includes  a  prototype 
implementation  that  uses  additional  type  annotations  to  make  typing  practically  syntax  directed. 
Note  that  more  practical  implementations  may  reduce  some  of  the  annotation  overhead  of  [21]  by 
pushing  additional  verification  complexity  to  the  type  checker  (i.e.  trade  annotations  for  “type¬ 
searching”  algorithms).  In  here  we  focus  on  the  core  issue  of  decidability  of  protocol  composition 
without  the  need  for  additional  type  annotations  beyond  the  initial  resource  to  be  split  and  the  two 
resulting  protocols. 

Our  subtyping  algorithm  uses  a  variant  of  the  algorithm  described  in  [2]  to  ensure  decidability 
of  subtyping  on  recursive  types.  The  main  distinction  is  that  our  recursive  types  include  parameters, 
thus  our  recursive  types  may  include  arguments  that  introduce  subtle  decidability  issues.  For  this 
reason,  our  focus  is  on  treating  the  new  problems  in  a  clear  way.  For  instance,  to  avoid  the  general 
undecidability  of  subtyping  over  bounded  quantification  [26]  we  use  the  subtyping  rule  of  F<:  [27], 
although  other  more  flexible  subtyping  rules  exists  [6] . 

Note  that  both  both  (st:Pack*)  and  (st:*App)  rules  use  a  unification  algorithm  that  searches  for 
a  single  type/location  match  to  be  used  in  the  rule.  Since  we  at  most  traverse  the  type  structure  to 
find  such  a  type/location,  the  algorithm  naturally  terminates  through  the  same  reasoning  as  with 
subtyping.  Type  equality  follows  similar  reasoning.  Therefore,  our  reasoning  assumes  that  there 
exists  a  decidable,  sound,  and  complete  unification  ( A{B/X }  =  C)  and  equality  (A  =  B)  algorithms. 
Finally,  also  note  that  we  do  not  consider  types  (such  as  ±  =  rec  X.X )  to  be  well-formed  types. 
Since  we  use  the  same  cycle  detection  technique  of  [2],  allowing  these  types  could  yield  wrong 
results. 

1.1  Ensuring  Regular  Type  Structure 

Both  subtype  and  protocol  composition  algorithms  may  have  to  recur  on  the  inner  sub-terms  of 
a  type.  For  instance,  checking  that  int  -o  bool  <:  string  -o  double  is  not  valid  requires 
checking  string  <:  int  and  bool  <:  double,  c.f.  (st:Function).  Consequently,  it  becomes 
important  to  ensure  that  the  set  of  sub-terms  of  a  type  is  finite  so  that  we  can  be  sure  both  algorithms 
will  converge  to  a  result  after  an  arbitrary,  but  finite,  number  of  recursive  steps.  The  main  problem 
is  in  finding  a  bound  on  the  unfolding  of  recursive  types.  More  specifically,  we  must  ensure  that 
our  use  of  recursive  types  with  parameters  still  produces  types  that  are  regular  in  their  structure, 
regardless  of  the  arguments  used. 

Both  subtype  and  protocol  composition  will  build  a  co-inductive  proof.  The  corresponding  al¬ 
gorithm  will  only  terminate  if  the  proof  reaches  a  “loop”  in  its  derivation  that  closes  the  derivation. 
Consequently,  we  must  show  that  any  well-formed  type  will  enable  such  a  loop  to  be  reached.  The 
fundamental  property  is  to  ensure  that  the  structure  of  the  derivation  is  regular.  In  our  system,  be¬ 
cause  we  have  both  parametric  polymorphism  and  recursive  types  with  parameters,  ensuring  this 
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regularity  is  non-trivial  and  requires  more  than  strict  derivation  equality. 

For  our  purposes  here,  our  equivalence  relation  will  only  consider  renaming  of  type/location 
variables  and  weakening  of  assumptions.  Consequently,  we  will  impose  well-formedness  condi¬ 
tions  on  our  types  to  ensure  that  any  well-formed  type  will  produce  derivations  that  are  equivalent 
up  to  those  two  conditions.  We  leave  as  future  work  devising  other,  perhaps  less  restrictive,  well- 
formedness  conditions  and  equivalences  since  our  focus  here  is  to  discuss  the  implementation  of 
protocol  composition  in  the  clearest  possible  terms. 

To  illustrate  an  irregular  unfold,  consider  for  instance  the  following  recursive  type,  R,  that  uses 
a  single  (type)  parameter,  X: 


(rec  R(X).(  int  -o  R[X  -o  X]  ))[int]  (Ex.l) 

Unfolding  this  type,  and  its  resulting  sub-terms,  produces  the  following  sequence  of  types  (we 
underline  the  “fixed”  part  of  the  recursive  type  to  highlight  how  that  same  unfold  produces  irregular 
types  over  its  argument): 

(rec  R(X).(  int  -o  R[X  -o  X]  ))  [int] 
int  -o  (rec  R(X).(  int  -o  X[X  -o  X] ))  [int  -o  int] 
int  -o  int  -o  (rec  R(X).(  int  -o  X[X  -o  X] ))  [(int  -o  int)  -o  (int  -o  int)] 


for  clarity,  we  replace  the  underlined  type  with  just  R  to  highlight  the  irregular  set  of  sub-terms: 

R[  int] 

int  -o  X[int  -o  int] 

int  -o  int  -o  X[(int  -o  int)  -o  (int  -o  int)] 


We  see  that  the  type  that  results  from  unfolding  is  not  regular,  as  the  use  of  the  recursive  variable 
R  in  “rec  R(X).(  int  -o  R[X  -o  X] )”  produces  a  type  that  is  non-repeating.  Consequently,  if  such 
a  use  were  allowed,  it  would  make  it  impossible  for  an  algorithm  that  traverses  all  sub-terms  of 
a  type  to  terminate  since  the  type  above  does  not  present  a  finite,  regular  structure  due  to  its  ever 
growing  argument  that  is  applied  to  the  recursive  type  R. 

To  forbid  uses  such  as  the  one  above,  we  limit  the  kind  of  arguments  that  may  be  applied  to  a 
recursive  type  variable  (such  as  R  above)  via  well-formedness  rules  (for  the  full  set  of  rules,  see 
G.l).  We  restrict  the  arguments  that  can  be  applied  to  a  recursive  type  variable  to  be  limited  to 
location  variables  or  type  variables,  and  exclude  recursive  type  variables: 

(X  :  k0  — >  ...  ->  kn  — >  type)  6  T  (U,  :  kt)  e  T  i  e  {0, ...,  n} 

T  h  X[U]  type 

The  rule  states  that  for  a  given  recursive  type  variable  X  (recursive  type  variables  have  a  “...  — > 
type”  kind),  its  arguments  (U)  must  each  be  an  assumption  of  compatible  kind  ((£/,  :  k,)  e  T). 
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Since  we  are  considering  each  individual  k,  of  X ,  these  can  only  be  either  a  loc  or  a  type  (and  never 
of  the  form  — >  type”)  which  effectively  enforces  that  only  location  variables  or  (non-recursive) 
type  variables  can  be  used  in  this  context.  Thus,  applications  of  the  form  /^[/^]  are  forbidden  since 
R  is  a  recursive  type  variable,  and  R\X  -o  X]  is  also  forbidden  since  the  argument  is  of  a  function 
type  (not  a  type/location  variable). 

Note,  however,  that  the  argument  applied  to  the  recursive  type  is  not  restricted  to  just  type/lo¬ 
cation  variables  and  instead  is  only  required  to  be  of  the  desired  kind: 

u0  :  kQ, ...,  u„  :  kn,X  :  k0  -»  ...  -»  k„  — >  type  b  A  type 
T  b  Ui  k{  ki  =  kind(w,)  i  e  {0,  ...,n} 

T  b  (rec  Xiu).A)\U\  type 

where:  lcind(7)  =  loc  and  kind(X)  =  type.  Thus,  using  int  as  argument  in  (rec  X(X).A)[int] 
is  legal.  However,  because  we  only  allow  each  parameter  of  a  recursive  type  to  be  either  of  kind 
type  or  kind  loc,  recursive  type  variables  cannot  appear  as  arguments  (in  U )  even  in  this  situation. 
To  preserve  the  well-formedness  condition  on  uses  of  X[I/']  we  must  also  avoid  situations  where 
substitution  from  other  recs  may  replace  some  argument  in  U'  with  a  non-variable  type  before  X 
is  unfolded.  Therefore,  the  body  of  rec,  i.e.  A ,  must  ignore  all  other  variables  that  are  outside  the 
top-level  rec,  so  that  substitution  of  any  element  in  U'  will  only  occur  as  the  rec  is  unfolded. 

However,  only  using  the  restrictions  above  is  still  not  sufficient  to  ensure  that  the  algorithms 
will  terminate,  since  the  resulting  set  of  sub-terms  may  still  be  irregular.  Consider  the  following 
type: 

(rec  V(Z).(VX  <:  (A  -o  Z).C[X]))[int]  (Ex.2) 

If  we  traverse  the  sub-terms  of  this  type,  we  see  that  the  typing  context  of  the  “V[X]”  sub-term  is 
irregular,  although  the  type  structure  of  V[.„]  itself  remains  regular. 

To  illustrate  this,  we  are  going  to  look  into  multiple  unfolds  of  V  but  only  show  the  premise 
that  is  used  to  check  that  V[.„]  is  well-formed.  To  highlight  the  renaming  on  each  unfold,  each 
new  use  of  X  is  indexed  with  ever  growing  integers.  Although  we  are  traversing  the  rec’s  sub¬ 
terms  (automatically  unfolding  V  to  continue  such  traversal),  we  omit  all  “:  type”  assertions  to 
focus  instead  on  the  typing  context  that  is  used  to  check  that ‘T  b  V[.„]  type”  (i.e.  that  V[.„]  is 
well-formed): 

•  b  V[int] 

X0  <:  A  -o  int  b  V[X0] 

Xv  <:  A  -o  X0,  X0  <:  A  -o  int  b  V[X{\ 

X2  <’.  A  —o  X\,  X\  <:  A  — o  XQ,  X0  <:  A  -o  int  b  V[X2] 

Consequently,  for  a  recursive  type  to  be  well-formed  we  must  also  ensure  that  the  enclosing  context 
of  future  unfolds  is  regular  since  it  is  not  enough  to  only  look  at  the  type’s  structure  alone. 

We  restrict  the  type  of  the  bound  of  a  V  or  3  such  that  the  bound  must  be  well-formed  in 
the  empty  context  “•  b  A  type”  in  any  “3X  <:  A.fi”  or  “VX  <:  A.S”  types  via  the  following 
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well-formdness  conditions: 

•  h  A0  type  r,X  :  type,X  <:  A0  h  A{  type  •  h  A0  type  Y,X  :  type,  Ac  A0  i-  Ai  type 
T  h  VXcAqAi  type  T  h  3A<:A0.Ai  type 

These  conditions  naturally  ensure  that  the  typing  contexts  in  a  type  must  be  regular  since  the  typing 
context  is  essentially  fixed  and  cannot  change  on  each  unfold.  We  leave  as  future  work  relaxing 
this  condition,  but  for  our  discussion  here,  this  well-formedness  restriction  is  enough  to  type  our 
examples  and  provides  an  interesting  domain  for  checking  safe  protocol  composition. 

Still,  our  constraints  enable  some  flexibility  such  as  the  case  of  the  following  type,  that  can  be 
considered  regular  by  considering  renaming  of  variables  and  weakening: 

(rec  M(Y).{Y  -o  MX  <:  top.M[A]))[int]  (Ex.3) 

As  above,  we  illustrate  the  case  via  successive  unfolds  but  only  show  the  typing  context  used 
to  check  that  T  h  M[...]  type  (i.e.  that  M[...]  is  well-formed): 

•  h  M[int] 

X0  <:  top  h  M[X (,] 

Xi  <:  top,X0  <:  top  h  M[X i] 

X2  <:  top,Xj  <:  top,X0  <:  top  h  M[X2\ 

By  inversion  on  weakening  of  assumptions,  we  can  consider  the  last  context  to  only  really  require 
the  “A2  <:  top”  assumption  (since  the  other  variables  do  not  occur  in  M\X2\).  By  renaming  X0 
and  X2  to  some  fresh  variable,  both  the  first  and  third  types  can  be  deduced  equivalent  (=) — which 
would  enable  to  close  a  co-inductive  proof  that  traverses  M’s  sub-terms. 

Z  <:  top  h  M[Z]  =  Z  <:  top  h  M[Z] 

(X2  <:  top){Z/X2}  h  (M[X2]){Z/X2)  =  (X0  <:  top ){Z/X0}  h  (MgTO 

X2  <:  top,^  <:  top,X0  <:  top  h  M[X2\  =  X0  <:  top  h  M[X0\ 

Thus,  we  consider  equivalence  up  to  renaming  of  variables  and  weakening  of  assumptions — 
besides  the  other  restrictions  discussed  above. 

1.1.1  Finite  Sub-terms 

We  now  discuss  the  regularity  of  the  structure  of  our  well-formed  types.  These  lemmas  are  essential 
to  show  that  there  is  a  bound  in  the  number  of  members  of  the  set  of  types  that  an  algorithm  will 
recur  on.  Thus,  when  we  recur  on  some  type’s  sub-term,  the  domain  of  possible  sub-terms  of  that 
type  must  necessarily  be  monotonically  shrinking  since  its  set  of  distinct  sub-terms  is  bounded  by 
a  finite  number.  To  simplify  the  discussion,  instead  of  counting  the  exact  size  of  the  set  of  distinct 
sub-terms  of  a  type,  our  proofs  will  often  resort  to  simpler  overapproximations  of  that  set.  Since 
even  the  dimension  of  that  overapproximation  is  finite,  then  the  set  of  distinct  sub-terms  of  any 
well-formed  type  will  also  necessarily  be  finite. 
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sts(  r  h  none  ) 

= 

{  r  h  none  } 

sts(  r  h  top  ) 

= 

{ r  h  top } 

sts(  r  h  ref  p) 

= 

{  r  b  ref  p  } 

sts(  T  h  rw  p  A  ) 

= 

{  T  h  rw  p  A  }  U  sts(  T  h  A  ) 

sts(  T  h  !A  ) 

= 

{ r  h  !A }  u  sts(  r  h  a  ) 

sts(  r  b  A  -o  B  ) 

= 

{  r  h  A  -o  B  }  U  sts(  r  b  A  )  U  sts(  Tb  B) 

sts(  T  b  A  : :  B ) 

= 

{  r  b  A  ::  B  }  U  sts(  T  b  A  )  U  sts(  Y  b  B  ) 

sts(  T  b  A  *  B  ) 

= 

{ r  b  a  *  b  }  u  sts(  r  b  a  )  u  sts(  r  b  b  ) 

sts(  T  b  A  ©  B  ) 

= 

{  r  b  A  ®  B  }  U  sts(  r  b  A  )  U  sts(  TbB) 

sts(  T\-A&B) 

= 

{  r  b  A&fi  }  U  sts(  r  b  A  )  U  sts(  TbB) 

sts(  T  b  A  =>  B  ) 

= 

{TbA^B}  U  sts(  r  b  A  )  U  sts(  TbB) 

sts(  T  h  A  ;  B  ) 

= 

{  r  b  A  ;  B  }  U  sts(  T  b  A  )  U  sts(  TbB) 

sts(  T  h  [f  :  A]  ) 

= 

{  T  b  [f  :  A]  }  U  U«sts(rb  A,-) 

sts(  r  h  2/ 1 j#Aj ) 

= 

{ r  b  Zi  tfiAi }  U  u#  sts(  r  b  a,  ) 

sts(  r  h  Ml. A  ) 

= 

{  r  b  Ml. A  }  U  sts(  T,  / :  loc  b  A  ) 

sts(  T  h  3/.A  ) 

= 

{  r  b  31. A  }  U  sts(  T,  / :  loc  b  A  ) 

sts(Tb  MXcA.B) 

= 

{  T  b  MXcA.B  }  U  sts(  •  b  A  )  U  sts(  Y,X  :  type,  A  <:  A  b  B  ) 

sts(Tb  3AcA.fi) 

= 

{  T  b  3X<: A.B  }  U  sts(  •  b  A  )  U  sts(  T, X  :  type, A  <:AbB) 

sts(  r  h  x[77] ) 

= 

{  T  b  X[U]  } 

sts(  r  b  (rec  X(u).A)[U] ) 

= 

{  T  b  (rec  X(u).A)[U]  }  U  sts(  Y  b  A{(rec  X(u).A)/X}{U /u) ) 

Note:  we  omit  type  from  T  I-  A  type  for  conciseness. 

Figure  35:  Computing  the  (infinite)  set  of  sub-terms  of  a  type  (sts). 

Figure  35  shows  a  straightforward  way  to  compute  the  infinite  set  of  sub-terms  of  a  type.  The 
most  important  case  to  note  is  that  of  rec,  which  unfolds  the  recursive  type  and  then  continues 
the  analysis  over  the  unfolded  type.  Consequently,  sts’s  definition  may  not  terminate  if  we  do  not 
define  a  way  to  identify  repeating  sub-terms  and  stop  further  (unnecessary)  recursive  calls  to  sts. 

As  discussed  above,  we  consider  equivalence  (=)  up  to  renaming  of  variables  and  weakening 
of  assumptions  defined  as  follows  (for  any  two  well-formed  types,  and  such  that  any  premise  must 
also  obey  type  well-formedness): 


Tb  A 

=  T  b  A 

(equality) 

r0,ri  b  Ao 

=  T2,T3  b  Ai 

if  Ti  b  Ao  =  T3  b  Ai 

(weakening) 

To  b  Ao 

=  TibAj 

if  r0{Z/A}  b  A0{Z/A} 

=  Y{  {Z/  T}  b  A  j  \Z/  y}  and  Z  fresh 

(renaming  type) 

To  b  Aq 

=  TibAj 

if  Y0{l/t'}  b  A0{l/f}  = 

Y[{l/t}  b  A[{l/t }  and  /  fresh 

(renaming  loc) 

With  the  conditions  above,  we  can  approximate  the  infinite  set  of  sub-terms  computed  by  sts  with 
one  that  computes  an  equivalent  (up  to  renaming  and  weakening)  but  finite  set  since  we  are  just 
collapsing  equivalent  members  of  that  set  (i.e.  each  member  now  represents  the  class  of  types 
defined  up  to  renaming  and  weakening).  Thus,  the  algorithm  stopping  condition  would  simply 
have  to  carry  a  set  of  visited  sub-terms  and  not  recur  on  equivalent  sub-terms  that  it  already  visited. 
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st(  r  h  a  ) 


st(  r  i -  a,  0 ) 


st(  r  h  a,  v ) 

st(  r  h  none,  v ) 

st(  r  h  top,  v ) 

st(  r  b  ref  p,  v  ) 

st(  T  h  rw  p  A,  v  ) 

st(  T  h  !A,  v  ) 

st(  T  h  A  -o  B,  v  ) 

st(  T  b  A  : :  B,  v  ) 

st(  T  b  A*  B,v) 

st(  T  hAffiB,v) 

st(  T  hA&8,v) 

st(  T  b  A  =>  /?,  v  ) 

st(  T  b  A  ;  B,  v  ) 

st(  r  h  [I7a, v] ) 

st(  r  h  Yji  t i#At,  v ) 

st(  r  b  V/.A,  V  ) 

st(  r  b  31. A,  v  ) 

st(  r  h  VX<:A.B,v  ) 

st(Tb  3X<:A.B,  v) 

st(rhX[!7],v) 

st(  r  h  (rec  X(u).A)\U\,v  ) 


v  if  (F  b  A')ev  and  (F  b  A)  =  (F  b  A') 
v  u  {  r  h  none  } 
v  u  {  r  h  top  } 
v  U  {  T  b  ref  p  } 

v  U  {  T  b  rw  p  A  }  U  st( T  b  A,  v  ) 

v  u  { r  b  !A }  u  st(  r  b  a,  v ) 
v  u  { r  b  a  — o  b  }  u  st(  r  b  a,  v )  u  st(  r  b  5,  v ) 
vU{rbA::S)  U  st(  T  b  A,  v  )  U  st(  T  b  B,  v  ) 
v  u  { r  b  a  *  b  }  u  st(  r  b  a,  v )  u  st(  r  b  5,  v ) 
v  u  { r  b  a  ©  b  }  u  st(  r  b  a,  v )  u  st(  r  b  5,  v ) 
v  u  { r  b  a&b  }  u  st(  r  b  a,  v )  u  st(  r  b  5,  v ) 

v  u  { r  b  a  =>  b  }  u  st(  r  b  a,  v )  u  st(  r  b  5,  v ) 

vU{TbA;  B}  U  st( T  b  A,  v  )  U  st(  Y  b  B,  v  ) 

vujTb  [T7a]  }  u  u«  st(  r  b  At,  v ) 

vU{TbL  t/#A/ }  U  Ui  st(  r  b  Aj ,  V  ) 
v  U  {  r  b  V/.A  }  U  st(  r,  l :  loc  b  A,  v  ) 

v  U  {  r  b  31.A  }  U  st(  r,  / :  loc  b  A,  v  ) 

v  U  {  r  b  VXcA.B  }  U  st(  •  b  A,  v  )  U  st(  r,X  :  type,X  <:  A  b  B,  v  ) 
v  U  {  T  b  3X<:  A.B  }  U  st(  •  b  A,  v  )  U  st(  T,X  :  type,X  <:  A  b  B,  v  ) 

v  u  { r  b  x[U] } 

st(  T  b  A  {(rec  X(u).A)/X}{U /u},  v  U  {  T  b  (rec  X(u).A)[U]  } ) 


Where  v  is  a  set  of ‘T  b  A”  elements.  Note  that  the  rules  are  ordered  so  that  we  try  to  apply  the  = 
case  (and  detect  cycles)  before  using  any  of  the  remaining  rules. 


Figure  36:  Computing  the  set  of  sub-terms  of  a  type,  up  to  equivalence  (=). 
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Lemma  25  (Finite  Uses).  Given  a  well-formed  recursive  type  ( rec  X(u).A)\U\  the  number  of  pos¬ 
sible  uses  ofX  in  A  such  that  T  h  X[  U'\  type  is  bounded. 

Proof  Our  well-formedness  restrictions  enforce  that  any  well-formed  X\ U'\  can  only  contain  ei¬ 
ther  location  or  type  variables  in  the  U'  set.  For  those  variables  to  be  themselves  well-formed  they 
must  be  present  in  T.  Since  Y  is  necessarily  a  finite  set  of  assumptions  it  must  contain  a  finite 
number  of  different  location/type  variables. 

We  have  that  for  m  location/type  variables  in  Y  and  if  the  set  u  has  size  n,  then  there  exists  at 
most  mn  tuples  of  n  variables  (repetition  is  allowed  since  types  are  pure),  each  containing  different 
type/location  applications  that  can  be  used  in  a  well-formed  X[  U’  ]  type.  (Note  the  “at  most”  since 
we  are  ignoring  the  type/location  variable  distinction  and  just  counting  both  kinds  together.)  □ 

Lemma  26  (Finite  Unfolds).  Unfolding  a  well-formed  recursive  type  {rec  X{u).A)\U\  produces  a 
finite  set  of  variants  of  that  original  recursive  type  that  (at  most )  contains:  permutations  ofU,  or  a 
set  of  mixtures  ofU  with  some  type/location  variables  representing  a  class  of  equivalent  (=)  types. 

Proof.  By  the  well-formedness  conditions  on  X[U'\  we  have  that  U’  will  list  a  set  of  type/location 
variables,  which  include  the  recursive  type’s  parameters  (u).  Thus,  for  any  use  of  the  recursive 
type  variable  X  that  may  occur  in  rec,  we  have  two  cases: 

•  Either  U'  only  contains  uses  of  the  recursive  type’s  parameters  (i.e.  u). 

Then,  this  means  that  an  unfold  will  produce  a  (rec  X(u)A)[U ']  which,  at  most,  only  differs 
in  the  order  of  the  elements  in  U' .  (Recall  that  since  all  variables  in  A  cannot  be  bound  to 
elements  outside  the  top-level  rec,  A  remains  invariant  over  unfold.)  Consequently,  for  n 
elements  in  U  there  can  be  n"  different  orderings  in  U'  since  repetition  is  allowed  and  both 
U  and  U'  must  have  the  same  number  of  elements. 

•  Or  U'  contains  a  mixture  of  type/location  variables  (that  must  have  been  declared  by  a  V  or 
3  inside  the  rec)  combined  with  some  elements  of  u. 

Lets  consider  a  Vf  <:  B.X[Y]  use  inside  of  A.  When  this  type  is  unfolded,  we  obtain  a 
(rec  X(.. .).(...))[  Y\  type  where  Y  is  now  the  argument  of  that  rec  (rather  than  previously 
provided  top-level  arguments  that  were  used  in  the  top-level  rec).  Furthermore,  our  well- 
formedness  conditions  on  V  and  3  ensure  that  the  bound  inside  the  unfolded  rec  will  remain 
invariant  over  unfold,  so  that  future  unfolds  will  produce  equivalent  uses  of  T’s  (potentially 
renamed).  Because  by  well-formedness  conditions  the  bound  is  isolated  from  any  variable 
(i.e.  typed  in  the  empty  context),  this  ensures  that  future  unfolds  will  type  Y  in  a  T  that  is 
equivalent  up  to  weakening  (by  ignoring  past  uses  of  Y).  (Note  that  the  order  of  the  bounds 
in  T  is  not  important,  as  the  assumptions  in  Y  form  an  unordered  set.) 

Thus,  by  (Finite  Uses)  we  have  that  each  use  of  X  is  bounded  by  a  finite  number  of  different 
mixtures/permutations  of  location/type  variables  in  T.  Consequently,  the  set  of  types  repre¬ 
sented  by  all  the  different  unfolds  produces  a  finite  set  of  recursive  types  representing  the 
infinite  set  of  different  unfolds,  that  yet  is  equivalent  up  to  renaming  and  weakening  to  that 
finite  set. 
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Lets  assume  that  a  top-level  (rec  X(...).A)[...]  contains  x  number  of  different  uses  of  X  in 
A.  As  done  in  the  proof  of  (Finite  Uses)  we  know  that  each  variable  will  have  mn  tuples  of 
n  variables  for  a  T  context  containing  in  type/location  variables  and  where  X  expects  n  ar¬ 
guments.  Combining  those  variables  with  the  u  possible  number  of  different  concrete  types 
provided  in  the  top-level  rec  yields  ( m  +  u)n  possible  different  uses  on  each  X.  Consequently, 
for  x  uses  of  X,  we  can  estimate  x  *  (m  +  u)n  different  elements  in  the  set  if  we  are  overap¬ 
proximating  by  considering  that  all  uses  of  X  have  the  largest  set  of  T  that  may  appear  in  any 
use  of  X. 

We  conclude  by  combining  the  two  finite  sets. 

□ 

Lemma  27  (Finite  Sub-Terms).  Given  a  well-formed  type  A,  such  that  T  h  A  type,  the  set  of 
sub-terms  of  A  is  finite  up  to  renaming  of  variables  and  weakening  ofY. 

Proof  The  proof  is  reduced  to  showing  that  the  definition  of  st  (Figure  36)  terminates  and  that  st 
produces  a  set  that  is  equivalent  to  the  set  produced  by  sts  (Figure  35),  up  to  =  types.  Equivalence 
is  immediate  since  the  two  definitions  only  differ  in  the  tracking  of  v,  the  set  of  visited  sub-terms 
which  enables  st  to  stop  when  it  finds  a  repeating  sub-term  while  sts  continues  indefinitely  pro¬ 
ducing  types  that  are  actually  =. 

Termination  is  straightforward  as  it  follows  by  the  previous  lemmas.  There  is  a  finite  number 
of  different  types  that  any  recursive  type  can  generate  and  all  other  type  constructs  produce  a  finite 
number  of  sub-terms,  thus  traversing  this  set  of  types  must  eventually  stop.  Each  case  is  simply  an 
application  of  inversion  on  the  specific  well-formedness  condition,  followed  by  the  application  of 
the  induction  hypothesis  which  then  enables  us  to  conclude  that  the  combination  of  two  terminating 
recursive  calls  to  st  will  also  have  to  terminate.  Termination  on  the  recursive  type  case  follows 
immediately  by  the  eventual  exhaustion  of  the  finitely  many  different  sub-terms  that  its  unfold 
may  produce,  shown  in  (Finite  Unfolds),  and  that  st  will  have  to  visit. 

□ 


1.2  Protocol  Composition  Lemmas 

The  proofs  of  the  following  lemmas  are  generally  straightforward,  after  all  that  was  the  point  in 
using  an  axiomatic  definition  of  composition. 

Lemma  28  (stp  soundness).  For  some  v  and  well-formed  T,  R,  R[P ]  if  stp(r,7?,  ^[P],v)  then 
T  b  R  RIP],  if  the  step  is  not  in  v. 

Proof  Straightforward  to  show  by  induction  on  the  cases  of  stp.  Note  that  the  algorithm  (in  Sec¬ 
tion  F.l)  includes  a  comment  with  the  equivalent  axiomatic  rule  to  clarify  which  case  the  algorithm 
is  implementing.  We  highlight  cases  (4)  and  (5)  that  match  (eq:Rec)  since  the  axiomatic  definition 
is  defined  up  to  unfolding  of  recursive  types,  thus  these  two  cases  are  implicit  in  the  axiomatic 
definition.  Similarly,  cases  (10)  and  (11)  (also  for  (12)  and  (13))  make  explicit  that  either  case  of 
&  (and  ©)  suffices.  Although  they  match  a  single  rule  in  the  axiomatic  definition  this  is  because 
we  assume  that  both  &  are  ©  are  commutative  but  made  that  fact  explicit  in  the  algorithm.  □ 
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Lemma  29  (c  soundness).  Given  well-formed  T,  R,  P,  Q  if  c( T,  R,  P,  Q)  then  T  h  R  P  ||  Q. 


Proof.  The  proof  is  straightforward  by  induction  on  the  cases  of  the  algorithm  since  each  case  of 
the  algorithm  directly  matches  a  specific  rule  of  the  axiomatic  definition.  The  use  of  a  visited  set 
simply  tracks  the  derivation  of  composition  by  keeping  the  set  of  visited  configurations  as  we  go 
conclusion  to  premise  on  the  co-inductive  proof.  Thus,  the  lemma  can  be  restated  as:  “For  some  v 
and  well-formed  T,  R,  P,  Q  if  c(  T,  R,  P,  Q,v)  then  T  R  ^  P  \\  Q,  where  all  members  of  v  step.” 
We  have  that  case  (1)  we  conclude  by  induction  hypothesis  with  an  empty  v.  Case  (2)  we  apply 
(stp  soundness)  on  each  step  of  the  configuration,  apply  the  induction  hypothesis  on  the  recursive 
call  to  c  using  the  new  v,  and  then  use  the  steps  of  (stp  soundness)  and  the  induction  hypothesis 
to  conclude  by  (c:Step)  and  (c:AllStep).  □ 

Lemma  30  (stp  completeness).  For  well-formed  T,  R,  R[P ]  ifT  I -  R  ^  R[P]  then  stp(r,i?,^[P],  v) 
for  some  v  that  does  not  contain  the  step. 

Proof.  Straightforward  to  show  following  similar  reasoning  to  soundness.  □ 

Lemma  31  (c  completeness).  Given  well-formed  T,  R,  P,  Q  if  Y  h  R  ^  P  ||  Q  then  c(  T,  R,  P,  Q ). 

Proof.  Straightforward  to  show  following  similar  reasoning  to  soundness.  □ 

Lemma  32  (c  decidability).  Given  well-formed  T,  R ,  P.  Q  then  c(  T,  R,  P.  Q )  terminates. 

Proof.  The  proof  follows  immediately  by  the  (Finite  Sub-Terms)  lemma  as  it  ensure  that  R ,  P.  and 
Q  must  contain  a  finite  set  of  distinct  sub-terms.  Thus,  stepping  of  a  protocol  must  therefore  be 
bounded  in  the  number  of  protocol  configurations  that  the  algorithm  can  visit  and  consequently  c 
must  terminate. 

□ 

Subtyping  Extension  Further  below  we  show  that  sbt  is  sound,  complete,  and  decidable  so  it 
should  be  straightforward  to  show  that  even  when  we  add  the  subtyping  conditions,  c  remains  at 
least  sound  and  decidable.  The  problem  is  whether  protocol  composition  remains  complete  when 
we  consider  the  (c-rs:Subsumption)  stepping  rule  since  the  rule’s  conclusion  does  not  direct  the 
types  to  be  used  in  its  premise.  It  is  at  this  point  that  the  order  in  subtyping  the  components  of  a 
configuration  is  important.  We  see  that  a  protocol  that  obeys  (c-rs:Subsumption)  would  actually 
also  compose  safely  without  that  rule  being  present,  i.e.  (c-rs:Subsumption)  is  admissible.  Instead, 
(c-rs: Subsumption)  is  only  important  to  close  the  proof  “earlier”  by  reducing  the  number  of  con¬ 
figurations  that  we  need  to  visit  to  check  composition.  Thus,  c  remains  complete  without  the  need 
for  an  explicit  (c-rs:Subsumption). 

Lemma  33  ((c-rs:Subsumption)  admissible).  If  T  \-  R[  <:  Rq  and  (  F  h  R0  ^  P[P()]  )  i— >  C  and 
T  h  Pq  <:  P i  then  (  T  I-  Pi  ^  P[Pi]  )  i-»  C,  without  using  (c-rs:Subsumption). 

Proof.  The  proof  is  straightforward  as  composition  enforces  breaking  the  ©  and  &  cases,  and  the 
changes  to  (c-ss:Step)  and  (c-ps:Step)  ensure  congruence  of  subtyping  is  still  derivable.  Note  that 
there  are  no  rules  for  congruence  on  subtyping  over  protocols.  □ 
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1.3  Subtyping  Lemmas 

Lemma  34  (sbt  soundness).  Given  well-formed  T,  A,  B  if  sbt(r,  A,  B)  then  Y  \-  A  <:  B. 

Proof.  The  lemma  can  be  restated  as:  “For  some  t  and  given  well-formed  T,  A,  B  if  sbt(  T,  A,  B,  t) 
then  r  h  A  <:  B,  where  all  members  of  t  obey  the  same  equivalence”.  We  proceed  by  case  analysis 
on  each  case  of  the  algorithm.  Case  (1)  is  proven  by  induction  hypothesis  where  t  is  the  empty 
set.  The  following  cases  are  straightforward  as  we  include  the  comment  on  the  corresponding 
subtyping  rule  being  applied.  We  have  that  by  case  (2)  then  we  conclude  by  (st:Symmetry);  case 
(3)  we  conclude  by  induction  hypothesis  and  (st:ToLinear);  etc.  Cases  (17),  (18),  (19),  and  (20) 
match  the  unfolding  of  recursive  types  and  the  set  of  visited  subtyping  configurations  to  close  the 
co-inductive  proof  (which  is  left  implicit  in  the  co-inductive  proof  of  the  axiomatic  definition). 

□ 


Lemma  35  (sbt  completeness).  Given  well-formed  T,  A,  B  if  T  h  A  <:  B  then  sbt(T,  A,  B). 

Proof.  The  proof  proceeds  by  induction  on  the  derivation  of  T  h  A  <:  B  and  is  straightforward  as 
each  case  of  the  derivation  matches  a  sbt  case  directly.  We  include  a  comment  on  the  definition 
of  sbt  to  highlight  the  axiomatic  rule  that  is  being  modeled  in  the  algorithm. 

□ 

Lemma  36  (sbt  decidability).  Given  well-formed  types,  A  and  B.  and  a  well-formed  environment, 
T,  sbt(T,  A,  B)  terminates. 

Proof.  The  proof  follows  immediately  by  the  (Finite  Sub-Terms)  lemma.  It  suffices  to  see  that  each 
recursive  call  to  sbt  will  necessarily  be  “smaller”  in  the  sense  of  either  considering  a  type  that  is 
structurally  smaller  or  the  recursive  call  including  a  larger  trail  of  already  seen  unfolds,  even  if  the 
unfolded  type  may  not  be  smaller.  This  trail  represents  the  potentially  infinite  but  regular  (up  to 
renaming  of  variables  and  weakening  of  T)  “tree”  of  types  modeled  by  a  recursive  type.  Since  by 
(Finite  Sub-Terms)  we  know  that  unfolding  a  type  will  result  in  a  finite  number  of  sub-terms,  we 
know  that  the  sub-terms  that  sbt  will  visit  are  necessarily  shrinking  since  there  is  a  finite  number 
of  combinations  to  visit — even  when  considering  the  product  of  sub-terms  of  types  A  and  B.  By 
(17)  we  check  whether  a  type  was  already  “seen”,  which  ensures  termination  after  at  most  visiting 
all  those  combinations  of  sub-terms.  Therefore  there  is  an  upper  bound  on  the  set  of  types  to  visit, 
which  ensures  that  sbt  cannot  recur  indefinitely.  Thus,  sbt  must  terminate.  □ 
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